pressing enter does not dismiss alert dialog



19 years ago
14 years ago


(Reporter: cmaximus, Assigned: saari)



Firefox Tracking Flags

(Not tracked)


(Whiteboard: [nsbeta2-])



19 years ago
Overview Description: 

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

Steps to Reproduce: 

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 

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

19 years ago
changing qa contact on selected bugs from paulmac to
QA Contact: paulmac → elig

Comment 2

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

Comment 4

19 years ago
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.
Keywords: nsbeta2, pp

Comment 5

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

Comment 6

19 years ago
reassigning to saari, taking myself off the cc list.
Assignee: don → saari

Comment 7

19 years ago
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.
Priority: P3 → P2
Target Milestone: --- → M16

Comment 8

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

19 years ago
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
OS: All → Linux
Hardware: All → PC

Comment 10

19 years ago
Putting on [nsbeta2-] radar.
Whiteboard: [nsbeta2-]

Comment 11

19 years ago
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.
Keywords: nsbeta2, pp → dogfood

Comment 12

19 years ago
This was FIXED recently (there was another bug out there on this point). Works
today on win32 and linux builds.
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 13

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

Comment 14

19 years ago
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.
Adding keyword to bugs which already show a nsbeta2 triage value in the status 
whiteboard so the queries don't get screwed up.
Keywords: nsbeta2
Product: Core → Mozilla Application Suite
You need to log in before you can comment on or make changes to this bug.