Closed
Bug 120527
Opened 23 years ago
Closed 18 years ago
When another button has focus, default button is still marked as default
Categories
(SeaMonkey :: Themes, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
Future
People
(Reporter: ian, Assigned: pilgrim)
References
Details
(4 keywords)
Attachments
(1 file, 3 obsolete files)
99.72 KB,
image/jpeg
|
Details |
STEPS TO REPRODUCE File | Page Setup (or any other way of getting a dialog with two buttons) Focus the Cancel button ACTUAL RESULT Windows Classic: Both buttons are marked as default button (dark outline) Modern: OK button is still marked as default EXPECTED RESULT When another button has focus, the default button should lose its default button styling since hitting Enter will not activate it.
Comment 1•23 years ago
|
||
This seems like a <dialog> issue.... should <dialog> catch focus changes and twiddle the styling accordingly on buttons?
Comment 2•23 years ago
|
||
This behavior shouldn't really be limited to dialog.
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Comment 3•22 years ago
|
||
Sec508 subpart B § 1194.21 (c): "A well-defined on-screen indication of the current focus shall be provided that moves among interactive interface elements as the input focus changes."
Severity: minor → normal
Keywords: sec508
selected buttons: taskbar: cancel mozilla: help explorer: restore defaults default buttons is ok in all three dialogs notice that no button appears to be the default button in folder options, this is because the dialog is not active. notice that preferences (also not active) paints two buttons as default (it should paint zero as default, since it isn't active) supposing preferences were active, it should behave like the run dialog, only one button can be default, and if a button is selected, that button is default and the default default reverts to normal button status. when i activate the folder options dialog, the only default/selected button would be restore defaults, ok is just be a normal button.
Comment 5•20 years ago
|
||
*** Bug 255860 has been marked as a duplicate of this bug. ***
Is anyone working on this at all? 2 years inactive, and it's still a minor annoyance in the latest Firefox.
davemilford@gmail.com: of course not, are you volunteering?
Assignee: hewitt → themes
Status: ASSIGNED → NEW
QA Contact: pmac
If I could, I would. I've got plenty of experience with C++, but not with Mozilla or XUL. And I wouldn't know where to start. And I'm not sure if I need to get permission from my employer to work on the project at all (probably not, as it's IBM). My hunch is this would be a rather trivial thing for someone to fix if they were familiar with the code.
Comment 9•19 years ago
|
||
*** Bug 196945 has been marked as a duplicate of this bug. ***
Comment 10•19 years ago
|
||
*** Bug 254472 has been marked as a duplicate of this bug. ***
Comment 11•19 years ago
|
||
Assignee: themes → neil.parkwaycc.co.uk
Status: NEW → ASSIGNED
Attachment #191480 -
Flags: review?(aaronleventhal)
Comment 12•19 years ago
|
||
Comment on attachment 191480 [details] [diff] [review] Proposed patch I'm not a peer but the code looks okay to me.
Comment 13•19 years ago
|
||
Comment on attachment 191480 [details] [diff] [review] Proposed patch non-peer r= for the accessible-ness of it.
Attachment #191480 -
Flags: review?(aaronleventhal) → review+
Updated•19 years ago
|
Attachment #191480 -
Flags: superreview?(jag)
Attachment #191480 -
Flags: review?(mconnor)
Updated•19 years ago
|
Attachment #191480 -
Flags: superreview?(jag) → superreview+
Comment 14•19 years ago
|
||
Comment on attachment 191480 [details] [diff] [review] Proposed patch This has to be #ifdefed out on OS X.
Attachment #191480 -
Flags: review-
Comment 15•19 years ago
|
||
Comment on attachment 191480 [details] [diff] [review] Proposed patch r=me with Mano's comment addressed
Attachment #191480 -
Flags: review?(mconnor)
Attachment #191480 -
Flags: review-
Attachment #191480 -
Flags: review+
Comment 16•19 years ago
|
||
Do we have a separate bug for HTML, for darkening the border of the submit button case? For example, on Google, the default button has a darkened border in IE and Opera, but not in Firefox -- even when another button isn't focused.
Comment 17•19 years ago
|
||
Attachment #191480 -
Attachment is obsolete: true
Attachment #196640 -
Flags: review?(bugs.mano)
Comment 18•19 years ago
|
||
(In reply to comment #16) > Do we have a separate bug for HTML, for darkening the border of the submit > button case? For example, on Google, the default button has a darkened border in > IE and Opera, but not in Firefox -- even when another button isn't focused. I looked and looked but couldn't find it.. the closest I could get to was bug 102057. I've never paid attention to this problem before to be honest but it does seem very inconsistent! Can you file the bug ?
Comment 19•19 years ago
|
||
Comment on attachment 196640 [details] [diff] [review] Updated for Mac >Index: toolkit/content/widgets/dialog.xml >=================================================================== > #ifdef XP_MACOSX > <handler event="keypress" key="." modifiers="meta" phase="capturing" action="this.cancelDialog();"/> >+#else >+ <handler event="focus" phase="capturing"> >+ var btn = this.getButton(this.defaultButton); >+ if (btn) >+ btn.setAttribute("default", !(event.originalTarget instanceof Components.interfaces.nsIDOMXULButtonElement)); >+ </handler> >+ </handlers> > #endif > </handlers> <handlers> is closed outside of the #ifdef. r=mano with that fixed.
Attachment #196640 -
Flags: review?(bugs.mano) → review+
Comment 20•19 years ago
|
||
(In reply to comment #18) > (In reply to comment #16) > > Do we have a separate bug for HTML, for darkening the border of the submit > > button case? For example, on Google, the default button has a darkened border in > I looked and looked but couldn't find it.. the closest I could get to was bug > 102057. I think that is the bug we were looking for.
Comment 21•19 years ago
|
||
Attachment #196640 -
Attachment is obsolete: true
Comment 22•19 years ago
|
||
Comment on attachment 196801 [details] [diff] [review] Patch for check in mozilla/toolkit/content/widgets/dialog.xml 1.26 mozilla/xpfe/global/resources/content/bindings/dialog.xml 1.35 followup: mozilla/xpfe/global/resources/content/bindings/dialog.xml 1.36
Attachment #196801 -
Attachment is obsolete: true
Comment 23•19 years ago
|
||
Comment on attachment 196801 [details] [diff] [review] Patch for check in a=me for SM1.0b on SM only part of code, one more needed
Comment 24•19 years ago
|
||
a=me for sm1.0b
Comment 25•19 years ago
|
||
(on the xpfe/ part. and with the followup included)
Comment 26•19 years ago
|
||
SeaMonkey-only portion of patch checked in to the 1.8 branch.
Whiteboard: fixed-seamonkey1.0
Updated•19 years ago
|
Keywords: fixed1.8.0.1,
fixed1.8.1
Comment 27•19 years ago
|
||
Sounds like this is fixed. Shouldn't it be closed now?
Comment 28•19 years ago
|
||
Comment on attachment 196801 [details] [diff] [review] Patch for check in Asking for 1.8.1 approval for the toolkit part.
Attachment #196801 -
Attachment is obsolete: false
Attachment #196801 -
Flags: branch-1.8.1?(mconnor)
Updated•19 years ago
|
Attachment #196801 -
Flags: branch-1.8.1?(mconnor) → branch-1.8.1+
Comment 29•19 years ago
|
||
Comment on attachment 196801 [details] [diff] [review] Patch for check in mozilla/toolkit/content/widgets/dialog.xml; new revision: 1.25.2.1;
Attachment #196801 -
Attachment is obsolete: true
Updated•18 years ago
|
Keywords: fixed-seamonkey1.0
Whiteboard: fixed-seamonkey1.0
Updated•18 years ago
|
Assignee: neil → pilgrim
Status: ASSIGNED → NEW
Assignee | ||
Updated•18 years ago
|
Whiteboard: [checkin needed]
Assignee | ||
Updated•18 years ago
|
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Whiteboard: [checkin needed]
Updated•16 years ago
|
Product: Core → SeaMonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•