Using Build ID: 2001042404 Just drag something to the Home button and weep. IIRC it used to say "Set Home Page" or "Cancel".
Works for me, w98 build 2001042504, when I drag URL to home button I get a dialog box asking if I would like to make this document your new home page with a yes and cancel button.
Yes, that's the problem :-) I assume this is a result of Conrad's changes, -> him
Assignee: blakeross → ccarlen
Since it asks "Do you want this to be your new home page?" what's wrong with "Yes" as an amswer?
Um = it's "OK" and "CANCEL" or "YES" and "NO" you shouldnt mix "yes" and "cancel"
Hokay, here's alerts in a nutshell. Alerts are interruptions to the user, so you should only use an alert if the user would be confused, endangered, or inconvenienced if you *didn't* use one. Usually the user will try to get rid of an alert without looking at its contents at all; so your first step is to never give alerts a close box, so the user has to at least *glance* at what's inside. Their second approach will be to try to guess the meaning of the alert just by reading the text of the buttons. If you're delivering an error message or an important note, obviously this just won't do. In this case you should always use `OK' for the button text, so as not to distract from the message, and to emphasize that the user really has to read the actual text of the alert rather than just the text of the button. But for a confirmation alert (such as this one), it's usually quite possible to communicate the basic intent of the alert through useful button text. So you should never use `Yes' and `No' as button text, as that forces the user to read the non-button text unnecessarily. You should use `Cancel' for a button that restores the system state to what it was before the action began, and you should use a verb or (very) short verb phrase for the button which performs the action which you're wanting confirmation for. In this case, the short verb phrase is `Set Home Page'.
OK, I can at least make it say "Yes" and "No". Matthew, I agree with most of your alert philosophy. However, the button title of this dialog changed as the result of an API change which was very much needed. There used to be a huge method by which arbitrary text could be specifed for up to four button titles. Embeddors complained bitterly about having to implement this method, so it was replaced by a new method by which standard button titles could be specified by constants. In determining that this was the thing to do, I searched the code base for uses of universalDialog which used nonstandard button titles and this was the only case. Every other confirmation dialog in the application uses Yes/No, OK/Cancel, or Save/Don't Save. This dialog will be consistent with those.
Sounds good to me
As I said, `Yes' and `No' are horrible as button text. They're better than `Yes' and `Cancel' (because at least `Yes' and `No' are symmetric), but they're not *that* much better. So `Yes' and `No' can certainly be checked in as a temporary improvement; but if the API does not allow the button to say `Set Home Page', then this bug should stay open until that bug in the API is fixed. Embedding is a secondary goal to producing a Web browser, so convenience for embeddors should not be used as an excuse to make Mozilla's UI worse. Other alerts which need (or will eventually need) to use text other than the strings you cited include: * the cookie acceptance alert (`Accept', `Cancel', and `Stop'); * the delete bookmark alert (`Delete' and `Cancel'); * the Windows Integration file associations alert (`Restore' and `Cancel'); * the folderless mail filter alert (`OK', `Delete Filter', and `Fix Filter ...'); * various alerts about insecure Web content (`Continue' and `Cancel'); * the offline connection alert (`Connect' and `Cancel'). Those are just the ones I can think of offhand.
I agree, on the "Yes/No" "OK/Cancel" symmetry. r=valeski on the 04/27/01 10:47 patch. nsIPromptService is strictly for throwing a pre-defined combination of dialogs and button values (and it does that well). We have to make iface design decisions every day that call for compromise between "browser" and "embedding" needs. Not allowing dynamic button text was, IMO, a small price to pay for a straightforward _prompting_ interface. If the _browser_ wants to throw this dialog w/ text "foo" in one of the buttons, then it can build out a special case XUL dialog to do so, using whatever interface it decides. I don't think anyone's forcing nsIPromptService on the world.
No, no one's forcing, but from what I gather you changed an interface that the UI depended on without providing any sort of interim alternative (or even warning/notifying the appropriate UI people), and that to me is not an acceptable `compromise'. Can the apps team turn around now, tweak your interfaces, and call it a compromise because it greatly boosted the usability of the UI at the expensive of the embedding effort?
Er, uh, `expense' While I'm here correcting my own idiocy, how does the desire to customize button text interfere with the desire to provide a straightforward prompting interface? Can't we have another, more customizable alert?
Summary: Drag to Home button asks Yes or Cancel → No longer able to specify button text in common dialogs
"Can the apps team turn around now, tweak your interfaces, and call it a compromise because it greatly boosted the usability of the UI at the expensive of the embedding effort?" no. discussion of the new interface was done openly in public api review meetings, and via postings to .embedding/.porkjockeys, if we took a wrong turn, we'll revisit it in nsIPromptService2.idl (a long way away hopefully). The interface is basically frozen (just lacking the javadoc "@status FROZEN" token at this point I believe). "how does the desire to customize button text interfere with the desire to provide a straightforward prompting interface?" customizing button text is what UniversalDialog did, and it is a *major* pain to implement that interface if your UI language is not XUL, therefore, it interfered w/ a straightforward prompting iface based on current priorities. "Can't we have another, more customizable alert?" of course, that is what I suggested someone do... valeski wrote: "If the _browser_ wants to throw this dialog w/ text "foo" in one of the buttons, then it can build out a special case XUL dialog to do so, using whatever interface it decides." changing summary from "No longer able to specify button text in common dialogs", back to the original summary. please don't morph this bug at this stage, we already have a patch submitted to get rid of *this* bug, please open a new one to address other concerns.
Summary: No longer able to specify button text in common dialogs → Drag to Home button asks Yes or Cancel
Sorry, you're right -- I can't complain. I just found the 'UniversalDialog must go away', which I was cc'd to, and in the original report it said that more complicated dialogs would need to use xul. > of course, that is what I suggested someone do... Okay, I guess we could do that. > we already have a patch submitted to get rid of *this* bug, please open a new > one to address other concerns. Well, not really. The bug asks what happened to Set Homepage. But anyways...
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
Sorry about the duplicate attachments. It told me the connection timed out... The proposed change to confirmEx would make it flexible enough but still simple to implement. The problem with universalDialog was not just that the button titles were dynamic but the the two text fields were visible or not and they were sometimes password fields and sometimes not. With a fairly small change to the implementation, I think this confirmEx could please all. Thoughts... In the meanwhile, brendan, can you sr the first patch?
Two points: - Why not get r= from module owner(s) and/or peer(s) who are affected by this change before getting sr=? - Should someone with more domain expertise than me sr? I can do it, but I'd defer to alecf or ben if they can add more value. /be
Fixed by checkin of bug 78745. This dialog, though, does not update until the cursor moves over it. That is bug 79040 and was happening before this checkin. Brendan, I didn't ask module owner review because this patch was merely going to change the text of buttons. I just chose somebody who can judge clear wording.
Status: ASSIGNED → RESOLVED
Last Resolved: 17 years ago
Resolution: --- → FIXED
I like the new wording, marking verified
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.