Closed Bug 77684 Opened 23 years ago Closed 23 years ago

Drag to Home button asks Yes or Cancel

Categories

(Core :: DOM: Copy & Paste and Drag & Drop, defect)

x86
Windows 95
defect
Not set
normal

Tracking

()

VERIFIED FIXED
mozilla0.9.1

People

(Reporter: neil, Assigned: ccarlen)

Details

Attachments

(3 files)

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...


-> 0.9.1
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?
Keywords: 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
Closed: 23 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.

Attachment

General

Created:
Updated:
Size: