29165 - pressing enter does not dismiss alert dialog

Status: VERIFIED FIXED

(SeaMonkey :: UI Design, defect, P2)

Description

[Claudius Gayle]

Overview Description: 

  This is a little muddy but basically when presented with an alert dialog, pressing 'enter' instead of clicking 'OK' doesn't always 
work.

Steps to Reproduce: 
IMPORTANT!

1) Launch Browser. For real. restart it, go ahead.

2) type foo: or whatever into the url field

3) when the resulting protocol error alert comes up type 'enter'.



Actual Results: 

	On Mac, it looks like the dialog does dismiss, only to reappear again each time you type enter. On linux, the dialog doesn't 
dismiss and an additional dialog appears. There will be one each for every time you press 'enter'. I can't repro on NT.

Expected Results: 

	For an alert dialog hitting enter should be logically equivalent to clickin 'OK'. In general, 'enter' should select the bolded 
choice.

Build Date & Platform Bug Found: 

	Mac 2000022408 and Linux 20000224115 builds.

Additional Builds and Platforms Tested On: 

	Not repro'd on WinNT 2000022414 so this is not really 'ALL' platforms.

Additional Info:

	The repro instructions call for a restart - that isn't strictly necessary. There is some combination of clicks that will cause this 
bug to revert to the correct behavior but i don't know what. If you don't restart you may inadvertantly do the clicks and then claim 
this 'works for you'.

	"But Claudius, it's just that dialog" - no not really, call up any alert you want. This will work too: Open Sidebar|Search panel. 
Click advanced. Deselect any selected engines. Click Results. Enter in a search string and click search. There's your alert, same 
behavior. I even got his to happen with the confirm Delete dialog from manage bookmarks (you must select Edit|Delete).

Waxing Intellectual:

	It is my belief that the key event is getting through somehow to wherever the focus was before. In the 1st example that 
would be the url bar where pressing enter with the same text there would simply trigger the dialog again. cc'd trudelle for the 
xptoolkit consult.

Comment 1

[Paul MacQuiddy]

changing qa contact on selected bugs from paulmac to [e-mail]

Comment 2

[Jesse Ruderman]

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

Comment 3

[Jesse Ruderman]

Bug 37262 had a test case: 
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=8006

Comment 4

[Claudius Gayle]

I can't believe this bug is still here. I almost wrote it up again!

Alerts don't go away until and unless you click with the mouse on Mac and Linux. grooving for some PDT love (marking nsbeta2)

I would've assigned this directly but I don't know who2bug on this one.

Comment 5

[prass]

It is very much alive and kicking :-(
I am copying danm since he might have better idea whom this should go to.

Comment 6

[Peter Trudelle]

reassigning to saari, taking myself off the cc list.

Comment 7

[saari (gone)]

I've been explicitly using the enter key instead of the mouse for the last day, 
and I have yet to see this on my Mac or WinNT box.

Comment 8

[prass]

This is more pronounced on linux. Atleast the bug I opened was for linux.  
Chris, please try the attached testcase on linux and using the enter key. On 
linux, it opens multiple alerts. Or if you want, I can drop by and show you 
several scenarios on linux seamonkey where this is a problem. thanks!

Comment 9

[Claudius Gayle]

I've satisfied myself that this somehow magically works fine on Mac with the 2000042709 builds.

But by the same token it repro's 100% on lInux with the 2000042709 builds. I've changed the platform/OS fields to reflect this change

Comment 10

[leger]

Putting on [nsbeta2-] radar.

Comment 11

[prass]

This is hitting aim users on linux really bad. For all user errors, we use 
alerts and with this bug, alerts pop up infinitely. Adding dogfoodto request a 
pdt review again.

Comment 12

[Peter Trudelle]

This was FIXED recently (there was another bug out there on this point). Works
today on win32 and linux builds.

Comment 13

[John Morrison]

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

Comment 14

[John Morrison]

This bug was for the case where dismissing an alert when focus was in the urlbar 
would get the key event (CR) delivered both to the alert dialog and back to the 
urlbar (resulting in another alert, and so on ad infinitum). That is fixed in 
current builds.

bug #37262, which was marked a duplicate of this bug, but it is not fixed -- 
it's not the same bug: On both windows and linux builds for today, using 
*either* the mouse or CR to dismiss the dialog, I get a second instance of the 
alert dialog thrown up. 

Reopening bug #37262, but this bug (#29165) is verified fixed.

Comment 15

[Daniel Veditz [:dveditz]]

Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.