Closed
Bug 99728
Opened 23 years ago
Closed 3 years ago
Modal dialogs do not block keyboard events (only mouse events)
Categories
(Core :: DOM: UI Events & Focus Handling, defect)
Tracking
()
RESOLVED
WORKSFORME
Future
People
(Reporter: bessettecm03, Unassigned)
References
Details
Attachments
(1 file)
(deleted),
text/html
|
Details |
From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.4) Gecko/20010913
BuildID: 20011091311
The JavaScript alert() box will open again if the mouse is focused on the
browser window (focus follows mouse in my window manager) and enter is hit.
This is inconsistant because if you attempt to click on the button that the
enter triggered, it doesn't allow it because of the first alert box..
Reproducible: Always
Steps to Reproduce:
1. go to page with an alert pop-up triggered by a button onClick
2. click the button to trigger the alert
3. attempt to click on the button again (without having closed the first alert;
you will notice it won't work)
4. move focus back to main browser (without closing original alert box)
5. hit enter (a new alert will pop up when it shouldn't)
Actual Results: same alert pops open
Expected Results: no second alert box
Comment 1•23 years ago
|
||
This actually has to do with the fact that _all_ keyboard events are allowed
through when modal dialogs are up. See also bug 99252 for a site which focuses
the page so one can type in a form and even submit it (using tab and enter) all
with a modal alert up.
Bug 65521 has a patch which claims to also fix this...
Comment 2•23 years ago
|
||
could reproduce the bug on RedHat Linux 7.1 BuildID: 2001-09-14 0.9.4
Seems to be specific to Linux only.
see the attached testcase
Comment 3•23 years ago
|
||
Comment 4•23 years ago
|
||
okay... linux should really have modal dialogs, even in mouse focus tracking
window manager setups. If that isn't how linux works, there isn't much to be
done about it.
->danm to decide if he can/should do anything about this bug
Assignee: joki → danm
gtk modality is pretty broken. here's hoping that whatever eventually shakes out
of bug 65521 will work for this bug, too.
Target Milestone: --- → mozilla0.9.7
Comment 6•23 years ago
|
||
*** Bug 114474 has been marked as a duplicate of this bug. ***
Updated•23 years ago
|
QA Contact: madhur → rakeshmishra
Updated•22 years ago
|
QA Contact: rakeshmishra → trix
Comment 7•22 years ago
|
||
Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.3b) Gecko/20030228 Phoenix/0.5
This is still an issue on new builds. I noticed it while trying out the HTML
test suite at w3.org. Go to
http://www.w3.org/MarkUp/Test/HTML401/current/tests/sec18_2_3-BF-15.html and do
the test. Try dismissing the resultant dialog with the enter key...
Comment 8•18 years ago
|
||
This is still an issue. Since gtk has changed several versions since the bug was reviewed, maybe it can be fixed now?
Assignee | ||
Updated•6 years ago
|
Component: Event Handling → User events and focus handling
Comment 10•3 years ago
|
||
Marking this as Resolved > Worksforme since the issue doesn't happen on Ubuntu 20.04 on either of the latest Firefox versions.
If anyone is still able to reproduce this please re-open or file a new issue.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WORKSFORME
You need to log in
before you can comment on or make changes to this bug.
Description
•