Drag to Home button asks Yes or Cancel

VERIFIED FIXED in mozilla0.9.1

Status

()

Core
Drag and Drop
VERIFIED FIXED
17 years ago
17 years ago

People

(Reporter: neil@parkwaycc.co.uk, Assigned: Conrad Carlen (not reading bugmail))

Tracking

Trunk
mozilla0.9.1
x86
Windows 95
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(3 attachments)

(Reporter)

Description

17 years ago
Using Build ID: 2001042404

Just drag something to the Home button and weep.

IIRC it used to say "Set Home Page" or "Cancel".

Comment 1

17 years ago
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.  

Comment 2

17 years ago
Yes, that's the problem :-)

I assume this is a result of Conrad's changes, -> him
Assignee: blakeross → ccarlen
(Assignee)

Comment 3

17 years ago
Since it asks "Do you want this to be your new home page?" what's wrong with
"Yes" as an amswer?

Comment 4

17 years ago
Um = it's "OK" and "CANCEL"

or "YES" and "NO"

you shouldnt mix "yes" and "cancel"

Comment 5

17 years ago
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'.
(Assignee)

Comment 6

17 years ago
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.
(Assignee)

Comment 7

17 years ago
Created attachment 32432 [details] [diff] [review]
Patch to make it say "Yes" and "No"

Comment 8

17 years ago
Sounds good to me

Comment 9

17 years ago
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.

Comment 10

17 years ago
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.

Comment 11

17 years ago
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?

Comment 12

17 years ago
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

Comment 13

17 years ago
"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

Comment 14

17 years ago
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...


(Assignee)

Comment 15

17 years ago
-> 0.9.1
Status: NEW → ASSIGNED
Target Milestone: --- → mozilla0.9.1
(Assignee)

Comment 16

17 years ago
Created attachment 32878 [details] [diff] [review]
proposed confirmEx change
(Assignee)

Comment 17

17 years ago
Created attachment 32880 [details] [diff] [review]
proposed confirmEx change
(Assignee)

Comment 18

17 years ago
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?

Updated

17 years ago
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
(Assignee)

Comment 20

17 years ago
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

Comment 21

17 years ago
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.