Modal window allows browser navigation via backspace #4794
Comments
|
Originally by @tsuoanttila Please provide a test UI if you are able to. |
|
Originally by @felype87 The fix for #12899 seems to have fixed this issue. |
|
Originally by @zch Was deprioritized. |
|
Originally by @Artur- Is the real issue here that the modal window stays open, that backspace navigates back or both? |
|
Originally by @felype87 Actually preventing backspace seems to be a bit weird. I would expect one of the following behaviors when pressing backspace:
|
|
Originally by mkn@compart.com I can say, that we found this issue when the user wanted to click into a textfield and delete the text, but by accident missed the input field. So closing the window seems to be a bit a strange behavior for our use case.. But "Closes the window and do not navigate back." seems to be a valid behavior. |
|
Originally by @Artur- There is http://dev.vaadin.com/ticket/12739 for the fact that the back button leaves the modal window open. This should not happen because you can always use the browser back regardless of if backspace is blocked (and using back should move to the other view, not show a modal window related to the previous view). The question which remains for this ticket is then if it is expected behavior to trigger "back" in the browser when pressing backspace in a modal window. |
|
Originally by @hannuvaadin That's a tricky issue, because there are several contexts that might apply and each handle the situation in a slightly different manner. Let's think about how browsers handle modality. Native alert windows for example are absolutely modal (with slight differences). There's no escaping from them with backspace or the back button. You can't close the browser window or tab, and in some browsers the alert will even haunt you to different tabs. You are stuck until you acknowledge the alert. That kind of sets the tone for user expectations. In a web app, you use modal windows because you don't want users to fiddle with stuff in the background while you require them to complete a task inside the modal window. Usually, these windows' contents might be very context-specific and closely related to the data on the originating view. Another widely used but questionable strategy is to use modal dialogs to ask user confirmation in dangerous actions, eg. data deletion. Usually, the way out is a Cancel button and pressing ESC key should do the same thing. And finally, there are the infamous modal "monologue boxes" that actually don't require any action from the user, except to press the "OK, got it" button after a message. Traditionally, there's no way out from these except clicking the button or pressing the enter key. Considering everything above, I would say that it's highly unexpected for the browser to navigate back when a modal-like window is displayed on the screen. If the window would stay on visible, it might break the context of information inside the window. Also, a modal window should not close by pressing backspace, since it's the equivalent of pressing the browser's back button. This can cause a lot of unintended consequences in situations where users expect certain components to have keyboard focus and instead trigger a window close event. (In some cases it might seem like a logical idea to use backspace or back button to double as the ESC key and close the modal window, but this is highly unexpected functionality.) |
|
Originally by @Artur- Backspace is now ignored when the window is focused. Other solutions such as completely preventing navigation when a modal window is open would theoretically be better but does not seem possible to implement. |
|
Originally by @jdahlstrom Replying to Salonen:
For what it's worth, there actually seem to be more than just slight differences nowadays. For example, Firefox alerts are only "page-modal" - backspace, browser back, closing the tab still work as expected, whereas Chrome alerts block the whole browser window. |
|
Originally by mkn@compart.com does not work for me, sometimes the view in the background stays, but the URL is changing anyway or it does not work at all.. |
|
Originally by proaccountapp Updated prioritization date. |
|
Originally by @alvarezguille Modified the tests to cover the case when the backspace is on an input and the case when the backspace is in other part of the content panel |
|
Originally by @alvarezguille This fix could be risky as it depends on detecting editable components inside the modal window and shouldn't be included in a maintenance release. |
Originally by mkn@compart.com
If a modal window is opened and the user presses the backspace key, the browser navigation will make the view in the back change to the last view, modal window still openend.
This is quite ugly.. if I manually prevent functionality of the backspace inside the window the user cannot longer delete in TextFields...
Imported from https://dev.vaadin.com/ issue #13180
The text was updated successfully, but these errors were encountered: