Keypress event bubbles up to the alert

VERIFIED FIXED in mozilla0.9.2

Status

()

VERIFIED FIXED
18 years ago
18 years ago

People

(Reporter: bugzilla, Assigned: bugzilla)

Tracking

Trunk
mozilla0.9.2
x86
Windows 2000
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: fix in hand)

Attachments

(4 attachments)

(Assignee)

Description

18 years ago
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

18 years ago
Created attachment 25292 [details] [diff] [review]
testcase

Comment 2

18 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

18 years ago
Summary: Keypress event bubbles up to the alert → [MF][FIX?]Keypress event bubbles up to the alert

Comment 3

18 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

18 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
Setting milestone to mozilla0.9.1
Target Milestone: mozilla0.9 → mozilla0.9.1

Comment 6

18 years ago
QA Contact Update
QA Contact: bsharma → vladimire
(Assignee)

Comment 7

18 years ago
*** Bug 77326 has been marked as a duplicate of this bug. ***
(Assignee)

Comment 8

18 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.
Keywords: nsbeta1, nsCatFood

Comment 9

18 years ago
Not sure why, but the alert now stays up, marking works for me
Status: ASSIGNED → RESOLVED
Last Resolved: 18 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

18 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

18 years ago
Status: REOPENED → ASSIGNED
Summary: [FIX]Keypress event bubbles up to the alert → Keypress event bubbles up to the alert

Updated

18 years ago
Target Milestone: mozilla0.9.1 → mozilla0.9.2

Comment 11

18 years ago
this works fine on linux as of last night

Comment 12

18 years ago
Created attachment 35359 [details]
Testcase with input button.  Same behavior if type="submit", etc.

Comment 13

18 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

18 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

18 years ago
Created attachment 38342 [details] [diff] [review]
patch
(Assignee)

Comment 16

18 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

18 years ago
r=kerz
(Assignee)

Updated

18 years ago
Whiteboard: fix in hand
(Assignee)

Comment 18

18 years ago
jst, sr?
Is this patch up to date? I don't see this code context in 
nsHTMLInputElement.cpp anymore. 
oh. lxr was feeding me crap.

hm. well, "seems" OK to me. sr=ben@netscape.com

Comment 21

18 years ago
a= asa@mozilla.org for checkin to the trunk.
(on behalf of drivers)
Blocks: 83989
(Assignee)

Comment 22

18 years ago
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 23

18 years ago
verifying build 2001-06-22-06-trunk windows 98
Status: RESOLVED → VERIFIED

Comment 24

18 years ago
The testcase that was attached works, but I have a new one that doesnt. Reopening
Status: VERIFIED → REOPENED
Resolution: FIXED → ---

Comment 25

18 years ago
Created attachment 41702 [details]
new testcase, click the document area and press space
(Assignee)

Comment 26

18 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
Last Resolved: 18 years ago18 years ago
Resolution: --- → FIXED

Comment 27

18 years ago
This patch causes a serious regression that could result in the form being 
submitted multiple times.  See bug 90392.

Comment 28

18 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.