ESC doesn't dismiss <dialog> unless it is focused
Categories
(Core :: DOM: Core & HTML, defect, P2)
Tracking
()
Tracking | Status | |
---|---|---|
firefox80 | --- | fixed |
People
(Reporter: aja, Assigned: sefeng)
References
()
Details
Attachments
(1 file)
User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:80.0) Gecko/20100101 Firefox/80.0
Steps to reproduce:
On MDN page https://developer.mozilla.org/en-US/docs/Web/HTML/Element/dialog on the "Advanced example", click "Update details" button, then press ESC without having focused the <details> "iframe".
Actual results:
ESC did not dismiss the <dialog>.
Expected results:
ESC should dismiss the <dialog>.
Reporter | ||
Updated•4 years ago
|
Assignee | ||
Updated•4 years ago
|
Comment 1•4 years ago
|
||
Somehow <select> implementation eats the esc key.
Updated•4 years ago
|
Assignee | ||
Comment 2•4 years ago
|
||
It turns out https://searchfox.org/mozilla-central/rev/e11d919cdc8a909354eb2c3e19904d9229c55d88/layout/forms/nsListControlFrame.cpp#2069 eats the event.
One challenge here is we don't have a flag to keep the status of the dropdown, and the dropdown is in the parent process, so it's hard to tell when should we preventing preventDefault()
.
Mike, do you have some suggestions?
Comment 3•4 years ago
|
||
While the <select> dropdown panel is indeed rendered in the parent process, the content process is told (via SelectChild.jsm) that the panel is open via this ChromeOnly WebIDL attribute: https://searchfox.org/mozilla-central/rev/91d82d7cbf05a71954dfa49d0e43824c7c973e62/layout/forms/nsComboboxControlFrame.h#162-164
So perhaps you could use that boolean to determine whether or not the preventDefault on the keypress.
Assignee | ||
Comment 4•4 years ago
|
||
We always use PreventDefault for <select> element, which is
problematic if modal dialog is on as it prevents cancelling
the dialog.
We fix it by not blocking the default action if <select> is
not shown.
Comment 6•4 years ago
|
||
bugherder |
Description
•