Closed Bug 78274 Opened 24 years ago Closed 20 years ago

Convert profile manager to use <dialog>

Categories

(SeaMonkey :: Startup & Profiles, defect, P4)

Product:
SeaMonkey
Component:
Startup & Profiles
Type:
defect

Tracking

(Not tracked)

Status:
RESOLVED FIXED
Milestone:
mozilla1.8beta1

People

(Reporter: bugzilla, Assigned: neil)

Details

(Keywords: access)

Attachments

(1 file, 3 obsolete files)

v1.1
(deleted), patch
jag+mozilla
: review+
sspitzer
: superreview+
Details | Diff | Splinter Review
like bug 78272, i thought a bug for this existed, but couldn't find one. dup as needed... anyhow, tabbing btwn the buttons in the Profile Manager and Manager User Profiles dialogs shifts the visual focus [highlight], but it does not activate. in other words, hitting enter [or escape] will not do anything when a button has focus. side note: if an item in the profile list has focus [selected and highlighted], only the enter key will work [which will launch the profile]; hitting the escape key will not dismiss the dialog [exit].
Keywords: nsbeta1, nsCatFood
QA Contact: sairuh → gbush
nav triage team: Reassigning to ccarlen, changing component to profile manager frontend
Assignee: ben → ccarlen
Component: Keyboard Navigation → Profile Manager FrontEnd
Keywords: access
-> vishy
Assignee: ccarlen → vishy
nav triage: my team is not going to be able to do this in mozilla0.9.2, does someone want to take it?
Keywords: nsbeta1, nsCatFood → nsbeta1+, nsCatFood-
Priority: -- → P4
Target Milestone: --- → mozilla1.0
Keywords: helpwanted
Looks like we are not updating the initial default command button in response to tabbing. When focus is tabbed to another command button, bold outline still stays on original default button, but should be updated. ->bryner, clearing target.
Assignee: vishy → bryner
Target Milestone: mozilla1.0 → ---
This is because the profile manager has not yet been converted to use <dialog>. Updating summary and reassigning.
Assignee: bryner → ben
QA Contact: gbush → ktrina
Summary: Profile Manager & Manage User Profiles dialogs need better keyboard support → Convert profile manager to use <dialog>
Status: NEW → ASSIGNED
Target Milestone: --- → Future
Just another dialog, dup of bug 102637. *** This bug has been marked as a duplicate of 102637 ***
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → DUPLICATE
Verified as a dupe of bug 102637
Status: RESOLVED → VERIFIED
Reopening because I have a patch.
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Attached patch Proposed patch (obsolete) (deleted) — — Splinter Review
Keywords: helpwanted → patch, review
Attachment #109235 - Flags: superreview?(dveditz)
Attachment #109235 - Flags: review+
Neil, several months since the patch was created - does the patch still work, and if so can anyone else sr? (Or am i missing something here?) (Adding you as cc)
jag, has the patch bitrotted at all, or is it okay?
Comment on attachment 109235 [details] [diff] [review] Proposed patch it still applies
Attachment #109235 - Flags: superreview?(dveditz) → superreview?(alecf)
Comment on attachment 109235 [details] [diff] [review] Proposed patch sr=alecf
Attachment #109235 - Flags: superreview?(alecf) → superreview+
.
Assignee: ben → neil
Status: REOPENED → NEW
Target Milestone: Future → mozilla1.4alpha
Fix checked in.
Status: NEW → RESOLVED
Closed: 23 years ago → 22 years ago
Resolution: --- → FIXED
I see an error in the console on linux: "chome://communicator/content/profileManager.js line 284: start has no properties". where start is 'start = document.getElementById('ok');'. Is this something left behind?
This swapped the positions of the Start/Cancel buttons on Mac. Very disturbing - the default button on Mac is always in the lower right, which it's no longer.
Backed out because of issues
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Attached patch work in progress (obsolete) (deleted) — — Splinter Review
Attached patch The One (obsolete) (deleted) — — Splinter Review
Attachment #109235 - Attachment is obsolete: true
Attachment #150981 - Attachment is obsolete: true
Attached patch v1.1 (deleted) — — Splinter Review
Forgot some CSS :-[
Attachment #151207 - Attachment is obsolete: true
Attachment #151485 - Flags: review?(jag)
Nice big patch. I'm looking forward to reviewing this over a big mug of home brewed coffee tomorrow.
Comment on attachment 151485 [details] [diff] [review] v1.1 >Index: profile/resources/locale/en-US/profileManager.properties Perhaps we should put quotes around the name of the button in the intro and switch text? Maybe some other day... >Index: themes/classic/global/mac/dialog.css >Index: themes/classic/global/win/dialog.css >Index: themes/modern/global/dialog.css Why do the margins need to be adjusted? Not saying this is wrong, just trying to understand. >@@ -236,22 +237,6 @@ >- // calling window.close() while an oncommand event >- // call is on the stack fails to close the window, >- // so we need to do this ugly setTimeout hack >- window.setTimeout( >- function(aDlgType) { >- document.documentElement._reallyDoButtonCommand(aDlgType); >- }, >- 0, aDlgType); >- ]]> >- </body> >- </method> >- >- <method name="_reallyDoButtonCommand"> >- <parameter name="aDlgType"/> >- <body> >- <![CDATA[ Is this part of the patch or some other bug? I know that hack was necessary at some point. Did we fix whatever bug was causing that? Looks good to me, r=jag
Attachment #151485 - Flags: review?(jag) → review+
(In reply to comment #23) >>Index: themes/classic/global/mac/dialog.css >>Index: themes/classic/global/win/dialog.css >>Index: themes/modern/global/dialog.css >Why do the margins need to be adjusted? Not saying this is wrong, just >trying to understand. We need to compensate for the default padding on <dialog> in order to be able to show the <dialogheader class="header-large"> in the correct position. >>- <method name="_reallyDoButtonCommand"> ><snip> >Is this part of the patch or some other bug? I know that hack was necessary >at some point. Did we fix whatever bug was causing that? Apparently so. I tried both windows and linux, and got someone with a Mac to try it on the mac, and it doesn't crash. I'm not to clear on the profile code but switching profile doesn't work too well from a timeout. I tried debugging it but it wouldn't break anywhere obvious. But I never did like that hack ;-)
Attachment #151485 - Flags: superreview?(alecf)
Attachment #151485 - Flags: superreview?(alecf) → superreview?(dveditz)
Comment on attachment 151485 [details] [diff] [review] v1.1 sr=sspitzer
Attachment #151485 - Flags: superreview?(dveditz) → superreview+
Target Milestone: mozilla1.4alpha → mozilla1.8beta
Fix checked in.
Status: REOPENED → RESOLVED
Closed: 22 years ago → 20 years ago
Resolution: --- → FIXED
Hmm, according to http://www.mozilla.org/projects/ui/accessibility/accesskey.html Ok and Cancel buttons shouldn't have accesskeys, but this patch introduced the attributes buttonaccesskeycancel and buttonaccesskeyaccept.
(In reply to comment #27) > Hmm, according to > > http://www.mozilla.org/projects/ui/accessibility/accesskey.html > > Ok and Cancel buttons shouldn't have accesskeys, but this patch introduced the > attributes buttonaccesskeycancel and buttonaccesskeyaccept. Oh, that was only for compatibility with ff, nobody actually uses it ;-)
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: