bug 298894 made [enter] fire the default button on mac, regardless of focus, but it also changed all platforms to that behavior. It is the wrong behavior for all other platforms.
Created attachment 188829 [details] [diff] [review] Proposed patch I first wrote this patch to fix bug 98070, and I've been running with it ever since; what I don't know is why I failed to attach it to that bug back then.
Assignee: nobody → neil.parkwaycc.co.uk
I was about to file a bug reporting pressing enter on the password dialog defaults to yes, but I see there already are comments in Bug 263532. I went looking for other dialog boxes to test out the "default button on enter" issue, and it does indeed fire the default. Should dataloss be added to the keywords? Pressing enter while the cancel button is selected for sanitize triggers the default action (sanitizing). Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.8b4) Gecko/20050728 Firefox/1.0+
It seems like the default button is *not* fired when pressing enter.. even on a mac. This picture of the new password dialog  shows that the default button is indeed "Not Now" (the blue shaded button) as well as the default selected button is "Not Now" (the blue outline). The default button is set correctly to "Not Now" (or at least rendered correctly), but pressing enter triggers the rightmost (position 0) button.  http://www.squarefree.com/burningedge/password-after.png
Comment on attachment 188829 [details] [diff] [review] Proposed patch r=jst
Attachment #188829 - Flags: review?(jst) → review+
Attachment #188829 - Flags: superreview?(peterv) → superreview?(bzbarsky)
I won't be able to really look for at least a week... I think bryner's sr should be quite sufficient to land this with. ;)
Comment on attachment 188829 [details] [diff] [review] Proposed patch So the idea here is that dispatch to the frame should be an at-target handler in the system event group, right? And that we can't quite do that yet, but this is close? Please add a comment to that effect before checking in... Get this in on trunk and request 1.8b4 approval, please?
Attachment #188829 - Flags: superreview?(bzbarsky) → superreview+
email@example.com (because of 304453)
Fix checked in to the trunk; waiting for it to bake before requesting approval.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Comment on attachment 188829 [details] [diff] [review] Proposed patch r=me for what it's worth
Attachment #188829 - Flags: review?(bryner) → review+
*** Bug 302571 has been marked as a duplicate of this bug. ***
[Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.9a1) Gecko/20050901 SeaMonkey/1.1a] (nightly) (W98SE) V.Fixed. (I checked with bug 302571 steps)
Status: RESOLVED → VERIFIED
Whiteboard: [needs review bryner, SR bzbarsky]
Comment on attachment 188829 [details] [diff] [review] Proposed patch No new regressions introduced by this regression fix :-)
Component: XP Toolkit/Widgets: XUL → XUL
QA Contact: xptoolkit.xul → xptoolkit.widgets
You need to log in before you can comment on or make changes to this bug.