Closed
Bug 68846
Opened 24 years ago
Closed 23 years ago
Keypress event bubbles up to the alert
Categories
(Core :: Layout: Form Controls, defect)
Tracking
()
VERIFIED
FIXED
mozilla0.9.2
People
(Reporter: bugzilla, Assigned: bugzilla)
References
Details
(Whiteboard: fix in hand)
Attachments
(4 files)
70 bytes,
patch
|
Details | Diff | Splinter Review | |
104 bytes,
text/html
|
Details | |
985 bytes,
patch
|
Details | Diff | Splinter Review | |
171 bytes,
text/html
|
Details |
Build ID: trunk (tip) Steps to Reproduce: (1) Open the attached testcase. (2) Focus the button (by tabbing to it or mousing down on then off of it). (3) Press spacebar. Result: the alert comes up fast and then disappears. You can tell that the keypress is reaching it because if you hold down spacebar until the dialog appears and then wait a second, the dialog's OK button goes :active. Note that while you're in there you might also want to fix this to only happen on keyup (new bug coming on that in a moment).
Assignee | ||
Comment 1•24 years ago
|
||
Comment 2•24 years ago
|
||
For whatever reason, when I test this with my current build and the fixes in my tree it works fine. So I am going to wait until I check in all my existing fixes and retest this.
Status: NEW → ASSIGNED
Updated•24 years ago
|
Summary: Keypress event bubbles up to the alert → [MF][FIX?]Keypress event bubbles up to the alert
Comment 3•24 years ago
|
||
This may be fixed
Summary: [MF][FIX?]Keypress event bubbles up to the alert → [MF][FIXED?]Keypress event bubbles up to the alert
Target Milestone: --- → mozilla0.9
Assignee | ||
Comment 4•24 years ago
|
||
Nope -- not on the tip, anyways. I can't imagine it's fixed in your local tree (but maybe); are you sure you're testing this properly?
Summary: [MF][FIXED?]Keypress event bubbles up to the alert → [MF][FIX]Keypress event bubbles up to the alert
Comment 5•24 years ago
|
||
Setting milestone to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1
Assignee | ||
Comment 8•23 years ago
|
||
Must fix for beta1, it poses security risks like the one documented in bug 77326, where the user agrees to save their password without even knowing (or making a conscious decision). It also has legal implications since users can bypass the one-time form submission warnings without ever being aware of their existence.
Comment 9•23 years ago
|
||
Not sure why, but the alert now stays up, marking works for me
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → WORKSFORME
Summary: [MF][FIX]Keypress event bubbles up to the alert → [FIX]Keypress event bubbles up to the alert
Assignee | ||
Comment 10•23 years ago
|
||
Still happens for input buttons (but masked by the spacebar scroll bug, fix being checked in later today). Odd that we need to have such separate handling for <button/> and input type="button" :-/
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
Updated•23 years ago
|
Status: REOPENED → ASSIGNED
Summary: [FIX]Keypress event bubbles up to the alert → Keypress event bubbles up to the alert
Updated•23 years ago
|
Target Milestone: mozilla0.9.1 → mozilla0.9.2
Comment 11•23 years ago
|
||
this works fine on linux as of last night
Comment 12•23 years ago
|
||
Comment 13•23 years ago
|
||
The bug still happens in the testcase I just attached, as mentioned by Blake on 05-01. Also cc: arik, just for the heck of it.
Comment 14•23 years ago
|
||
I think this is a focus issue or event targeting issue. When the <return> or <space bar> keys are hit the input button creates and send a left button click event which ends up calling nsGenericHTMLLeafFormElement::HandleDOMEvent (line 1078 of nsHTMLInputElement.cpp) which displays and cancels the dialog before it ever comes back to the nsHTMLInputElement. Also, note that pressing the space bar does not cause this to happen, but pressing the <ret> does. reassigning
Assignee: rods → saari
Status: ASSIGNED → NEW
Assignee | ||
Comment 15•23 years ago
|
||
Assignee | ||
Comment 16•23 years ago
|
||
Buttons should be triggering on keyup anyways, so this patch does the right thing (and fixes this problem).
Assignee: saari → blake
Comment 17•23 years ago
|
||
r=kerz
Assignee | ||
Updated•23 years ago
|
Whiteboard: fix in hand
Assignee | ||
Comment 18•23 years ago
|
||
jst, sr?
Comment 19•23 years ago
|
||
Is this patch up to date? I don't see this code context in nsHTMLInputElement.cpp anymore.
Comment 20•23 years ago
|
||
oh. lxr was feeding me crap. hm. well, "seems" OK to me. sr=ben@netscape.com
Comment 21•23 years ago
|
||
a= asa@mozilla.org for checkin to the trunk. (on behalf of drivers)
Blocks: 83989
Assignee | ||
Comment 22•23 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 24•23 years ago
|
||
The testcase that was attached works, but I have a new one that doesnt. Reopening
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
Comment 25•23 years ago
|
||
Assignee | ||
Comment 26•23 years ago
|
||
Well, right -- your testcase bypasses this fix. The real problem is essentially that onkeypress will continue to fire as long as you hold the key, targetting other elements that didn't get the original onkeydown. As far as I know, an element should only be able to get onkeypress if it's the same element that got the onkeydown. Vladimire, can you split that off into a separate bug (filed under Event Handling, and cc me)?
Status: REOPENED → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → FIXED
Comment 27•23 years ago
|
||
This patch causes a serious regression that could result in the form being submitted multiple times. See bug 90392.
Comment 28•23 years ago
|
||
Verified build 2001072406 branch os:win98,win2000
Status: RESOLVED → VERIFIED
You need to log in
before you can comment on or make changes to this bug.
Description
•