Skip to content
This repository has been archived by the owner on May 29, 2019. It is now read-only.

[modal] ESC key capture too aggressive #2544

Closed
stryju opened this issue Aug 5, 2014 · 12 comments
Closed

[modal] ESC key capture too aggressive #2544

stryju opened this issue Aug 5, 2014 · 12 comments

Comments

@stryju
Copy link
Contributor

stryju commented Aug 5, 2014

https://github.com/angular-ui/bootstrap/blob/master/src/modal/modal.js#L224-L232

it captures that globally without checking if event.target is an user input (<input type="text|number|checkbox|...">, <textarea>, <select>)

@dvidsilva
Copy link

so this can't be prevented or overwritten?

@wesleycho
Copy link
Contributor

For reference, the current lines are https://github.com/angular-ui/bootstrap/blob/master/src/modal/modal.js#L253-L265 .

@chrisirhc
Copy link
Contributor

Also, for reference, Twitter Bootstrap has the escape key listener only on the modal element itself rather than on the $document.

@chrisirhc chrisirhc modified the milestones: 0.13.1, 0.13.0 Apr 16, 2015
@stryju
Copy link
Contributor Author

stryju commented Apr 16, 2015

there you go

@karianna karianna removed the PRs plz! label Apr 16, 2015
@chrisirhc
Copy link
Contributor

Re-looking at this, what's the actual use case where this is breaking things? Why would a user need to type escape while inputting a form?

Changing this may break expected behavior (and deviates from Twitter Bootstrap's modal behavior). Typically, if a form control requires the use of the Escape key to perform some action, it should do event.stopPropagation() to prevent other components, such as the modal from capturing the escape key.

@stryju
Copy link
Contributor Author

stryju commented Apr 16, 2015

well, when i'm typing something in an input and i press escape (input still :focus), i expect the value to be gone, not closing of the "window" (modal, in that case)

@stryju
Copy link
Contributor Author

stryju commented Apr 16, 2015

IMO it would be better if developer explicitly triggered blur on the form elements when they're "empty" so the next esc key press would close the modal

@chrisirhc
Copy link
Contributor

Hm what kind of an input field is this? I don't think this is the default behavior in browsers. It's not the behavior in the input text boxes in GitHub for example. If a developer triggers blur, the developer should also stop the event from propagating or preventDefault.

@chrisirhc
Copy link
Contributor

I realized we can also check whether the event has default prevented to avoid closing the modal if the isDefaultPrevented returns true. That way, developers can signal that the keyboard event has been canceled and avoid closing the modal when event.preventDefault has been called.

@stryju
Copy link
Contributor Author

stryju commented Apr 17, 2015

hm - true

@chrisirhc
Copy link
Contributor

If you could modify your PR or create a new PR for that change, I'll be happy to get it merged 😄

@stryju
Copy link
Contributor Author

stryju commented Apr 23, 2015

ok, so that bugged me for a while...

  1. input[type="search"] is cleared (webkit/blink)
  2. input[type="date"] deactivates/collapses, when in active/expanded state
  3. select deactivates/collapses, when in active/expanded state

http://jsbin.com/quyavunemo/1/

@wesleycho wesleycho modified the milestones: 0.13.3 (Fixes), Backlog Aug 6, 2015
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

6 participants