Closed Bug 41518 Opened 25 years ago Closed 15 years ago

Drag-To-Home dialog tweaks

Categories

(SeaMonkey :: UI Design, enhancement)

enhancement
Not set
normal

Tracking

(Not tracked)

RESOLVED EXPIRED

People

(Reporter: bugs, Assigned: jag+mozilla)

Details

From Matthew Thomas: A few suggestions: * The dialog should tell me exactly what it is that I've dragged to the Home button -- both by URL, and by `"TITLE"' (if known) or `this document' if not. * If there is a checkbox so I can turn a dialog off, in the dialog itself, there MUST always be a checkbox somewhere else so I can turn it back on again (in case I turned it off by accident, or in case I change my mind later), and the dialog SHOULD tell me where that other checkbox is. In this case, it would be in the Navigator category of the Preferences dialog. Thus ... when the TITLE is known: +-------------------------------------------------------------+ |Set Home Page :::::::::::::::::::::::::::::::::::::::::::::::| +-------------------------------------------------------------+ | /\\ Do you want `Mozilla Design Preview' | | ||| <http://homepages.ihug.co.nz/~rgoodger/> to be your | | new home page? | | | | [*] Always check when I drag an address to the Home | | button (This can also be set in the `Navigator' | | category of Preferences) | | | | [[ Set Home Page ]] [ Cancel ] | +-------------------------------------------------------------+ And when the TITLE is not known: +-------------------------------------------------------------+ |Set Home Page :::::::::::::::::::::::::::::::::::::::::::::::| +-------------------------------------------------------------+ | /\\ Do you want this address | | ||| <http://homepages.ihug.co.nz/~rgoodger/> to be your | | new home page? | | | | [*] Always check when I drag an address to the Home | | button (This can also be set in the `Navigator' | | category of Preferences) | | | | [[ Set Home Page ]] [ Cancel ] | +-------------------------------------------------------------+
.
Assignee: don → ben
Status: NEW → ASSIGNED
Target Milestone: --- → M20
Ben, in n.p.m.ui you said `Some of the things you suggested (document link - which I wanted to originally also but could not think of an easy way to do) ...' Please note that I didn't intend the URL in the dialog to be a link, just a plain-text statement of the URL. Providing a link from within the dialog would have little value (the page is very likely to be open already anyway), and it would distract from the point of the dialog. If you were to make a custom dialog for this case, that would allow the URL to be put in a (non-editable) text field so the user could scroll to see the whole URL (which you wouldn't be able to do with a normal dialog).
OS: Windows NT → All
Hardware: PC → All
This is what I meant to say, sorry. I intend to modify this dialog to use a readonly scroll area
Yeah, I deserve a slap upside the head for that. For some reason I didn't read the whole of your message, and I ended up going off on the wrong tack entirely about what you meant -- not to mention suggesting things which you'd already said you were going to do! Duh. Meanwhile, I've been thinking about this some more, and I actually don't think the checkbox is necessary at all. Changing your home page is something you do very rarely, and I think users can put up with always having a dialog each time it happens. (Setting your home page this way will still be far quicker than it was before.) This dialog with the checkbox is about twice as complicated as it would be without the checkbox. And if you have the checkbox, it needs we counterpart `Warn me before setting the home page by dragging onto the Home button' checkbox in the prefs dialog, which -- no matter how you worded it -- would probably look really corny.
I'm gonna work on this
nm, I didn't realize how much of this was already implemented! Looks good so far, even the checkbox pref appears to be working (are we keeping this?) Does commonDialogService give you any control over the widgets used in the dialog (to put in the readonly textfield for the url)?
As of now, the following remains to make this dialog perfect (in the Classic skin), in descending order of importance: * Getting rid of the checkbox in the dialog, the associated checkbox in the prefs, and the pref itself (for reasons described above). * Changing of the text of the question, including the URL and (where known) title of the document, as shown in the initial picture Ben quoted from me. (It looks like work has already begun on this, judging by the content of the navigator.properties file.) * Making the dialog narrower. (Just getting rid of the checkbox may fix this automatically.) * Fixing the dialog text so that it uses CSS2's `message-box' font family (e.g. Charcoal 12 instead of Geneva 10 on Mac). This should be fixed as high up as possible, i.e. a general selector for top-level text elements in commonDialog.css. * Fixing the pixel padding around the outside of the dialog. Which is probably a job for nbhatla in commonDialog.css.
jrgm/claudius: which of you get this (in the absence of Mr Goldberg, for d'n'd boogz)? i don't b'lieve this is for me...
QA Contact: sairuh → jrgm
I'll QA this puppy i guess.
QA Contact: jrgm → claudius
spam: migrating drag'n'drop bugs to Terri.
QA Contact: claudius → tpreston
nav triage team: Other than a missing icon, no big deal, this looks pretty much done on today's Mozilla build. Marking nsbeta1-, it's a whole lot better than rtm.
Keywords: nsbeta1-
Marking nsbeta1- bugs as future to get off the radar.
Target Milestone: --- → Future
changing to enhancement
Severity: normal → enhancement
Product: Core → Mozilla Application Suite
Assignee: bugs → jag
Status: ASSIGNED → NEW
Priority: P3 → --
QA Contact: tpreston
Target Milestone: Future → ---
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state. If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way. If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar). If no action happens within the next few months, we move this bug report to an EXPIRED state. Query tag for this change: mass-UNCONFIRM-20090614
MASS-CHANGE: This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago. Because of this, we're resolving the bug as EXPIRED. If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component. Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 15 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.