Closed
Bug 63647
Opened 24 years ago
Closed 24 years ago
Element should have focus by default in common dialogs
Categories
(SeaMonkey :: UI Design, defect)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: bugzilla, Assigned: bugzilla)
References
Details
Attachments
(5 files)
10.81 KB,
patch
|
Details | Diff | Splinter Review | |
11.17 KB,
patch
|
Details | Diff | Splinter Review | |
10.97 KB,
patch
|
Details | Diff | Splinter Review | |
10.97 KB,
patch
|
Details | Diff | Splinter Review | |
6.32 KB,
patch
|
Details | Diff | Splinter Review |
One button in all common dialogs needs to have focus by default. I thought it
should be OK unless a Cancel button is present (in which case it'd be Cancel),
but consensus in #mozilla (and Windows standard) seems to be that the OK button
has focus.
However, I think the standard is actually to give focus to the button that
triggers the least harmful action. Since this isn't always necessarily cancel,
we'll need a way to let the caller choose. I'm attaching a patch that, for
now, provides the default focus defaults (under the assumption that no focus
was explicitly specified somewhere by the caller).
Assignee | ||
Comment 1•24 years ago
|
||
r=timeless w/ a minor warning about Cancel as default. Request someone provide
reference Human User Interface guidelines from Apple [macos], Microsoft
[windows], Sun [java] and Be [BeOS/BeBible].
Assignee | ||
Comment 4•24 years ago
|
||
Assignee | ||
Updated•24 years ago
|
Summary: Button should have focus by default in common dialogs → Element should have focus by default in common dialogs
Comment 5•24 years ago
|
||
The button that has the dark border (initially? bug 63728) should also start
with focus, I think. No new code for default defaults should be necessary.
I just made this bug block bug 52751, "Hitting return dismisses dialog when
default button disabled".
Btw, the phrase "common dialogs" usually means Windows save/print dialogs
(which are common across applications), but I'm assuming that you're talking
about dialogs with just text and buttons.
Assignee | ||
Comment 6•24 years ago
|
||
That black border needs to follow focus, not the other way around. I'm going
to file a separate bug for that later.
Assignee | ||
Comment 7•24 years ago
|
||
Assignee | ||
Comment 8•24 years ago
|
||
List, List, List, List, List. We agree they're lists :-)
r=timeless on 21294
Assignee | ||
Comment 10•24 years ago
|
||
Alec, can you sr?
Comment 11•24 years ago
|
||
any chance I can get a diff -bw? there's alot of indentation fixes there, not
sure where the real fix is.
Assignee | ||
Comment 12•24 years ago
|
||
Comment 13•24 years ago
|
||
thanks, this is pretty neat.
sr=alecf
Comment 14•24 years ago
|
||
Netscape nav triage team: as per Alec Flett's pre-triage recommendation, this
bug is nsbeta1-.
Keywords: nsbeta1-
Assignee | ||
Comment 15•24 years ago
|
||
Thanks, fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 16•24 years ago
|
||
tested this w/an alert dialog containing a textfield. eg, using an htaccess
dialog or the mailnews login dialog [used the former this time --the OK button
is in focus, and outlined in black]. vrfy fixed on linux, winnt and mac:
2001.02.09.08 comm bits.
Status: RESOLVED → VERIFIED
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
You need to log in
before you can comment on or make changes to this bug.
Description
•