68846 - Keypress event bubbles up to the alert

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Blake Ross]

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

Comment 1

[Blake Ross]

Attachment: testcase

Comment 2

[rods (gone)]

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.

Comment 3

[rods (gone)]

This may be fixed

Comment 4

[Blake Ross]

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?

Comment 5

[Kevin McCluskey (gone)]

Setting milestone to mozilla0.9.1

Comment 6

[Vladimir Ermakov]

QA Contact Update

Comment 7

[Blake Ross]

*** Bug 77326 has been marked as a duplicate of this bug. ***

Comment 8

[Blake Ross]

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

[rods (gone)]

Not sure why, but the alert now stays up, marking works for me

Comment 10

[Blake Ross]

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" :-/

Comment 11

[arik devens]

this works fine on linux as of last night

Comment 12

[:deanis74]

Attachment: Testcase with input button. Same behavior if type="submit", etc.

Comment 13

[:deanis74]

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

[rods (gone)]

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

Comment 15

[Blake Ross]

Attachment: patch

Comment 16

[Blake Ross]

Buttons should be triggering on keyup anyways, so this patch does the right 
thing (and fixes this problem).

Comment 17

[Jason Kersey]

r=kerz

Comment 18

[Blake Ross]

jst, sr?

Comment 19

[Ben Goodger (use ben at mozilla dot org for email)]

Is this patch up to date? I don't see this code context in 
nsHTMLInputElement.cpp anymore. 

Comment 20

[Ben Goodger (use ben at mozilla dot org for email)]

oh. lxr was feeding me crap.

hm. well, "seems" OK to me. sr=[e-mail]

Comment 21

[Asa Dotzler [:asa]]

a= [e-mail] for checkin to the trunk.
(on behalf of drivers)

Comment 22

[Blake Ross]

Fix checked in.

Comment 23

[Vladimir Ermakov]

verifying build 2001-06-22-06-trunk windows 98

Comment 24

[Vladimir Ermakov]

The testcase that was attached works, but I have a new one that doesnt. Reopening

Comment 25

[Vladimir Ermakov]

Attachment: new testcase, click the document area and press space

Comment 26

[Blake Ross]

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)?

Comment 27

[Eric Pollmann]

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

Comment 28

[jerone]

Verified build 2001072406 branch os:win98,win2000