64955 - Clean up Windows Integration alert for changed settings

Status: RESOLVED DUPLICATE of bug 380347

(SeaMonkey :: UI Design, defect)

Description

[Matthew Wilson]

From Bugzilla Helper:
User-Agent: Mozilla/4.0 (compatible; MSIE 5.0; Windows 98; DigExt)
BuildID:    0.7

The prompt "Do you want to update Windows to match your Desktop Integration 
preferences?" has three buttons: Yes, No, Cancel, but apparently only two 
actions: Yes, No.

Reproducible: Always
Steps to Reproduce:
1. Set up Mozilla preferences so that Mozilla is the default browser for HTML 
files.
2. Set up Windows so that the default browser is some other browser or 
application
3. Start up Mozilla

Actual Results:  A window appears saying "...Do you want to update Windows to 
match your Desktop Integration preferences?" (correctly). This has a checkbox 
("ask me next time") and three buttons, Yes, No, and Cancel. However, No and 
Cancel appear to have exactly the same effect.

Expected Results:  Either
a) Cancel should prevent the startup of Mozilla
or
b) There should only be two buttons, Yes and No.

Comment 1

[timeless]

=>UIDF first, cancel should quit. the dialog is under review for reorg.  This 
might be a dupe.

Comment 2

[David Hallowell]

We only need to have Yes ans No in this dialog because the user has indicated
they want to launch Mozilla and there is no reason why they'd want to quit the
browser after seeing this dialog box.

Comment 3

[Matthew T (active 1999-2002)]

If at all possible, buttons should use words more descriptive than `Yes' or `No' 
-- in this case, `Update' and `Ignore' would be appropriate.

[Windows only, QA --> Claudius]

Comment 4

[Matthew T (active 1999-2002)]

[really giving to Claudius this time]

Comment 5

[Jesse Ruderman]

I don't think "update" is appropriate as a button title, because changing file 
associations is an irreversible and potentially destructive action.

Comment 6

[Matthew T (active 1999-2002)]

Severity of action is an issue to be dealt with by the icon and text for the 
dialog, not by the text for the dialog's buttons.

Comment 7

[Fabian Guisset]

marking new, this dialog is indeed confusing cuz of this bug

Comment 8

[Zach Lipton [:zach]]

Chaning the qa contact on these bugs to me. MPT will be moving to the 
owner of this component shortly. I would like to thank him for all his hard 
work as he moves roles in mozilla.org...Yada, Yada, Yada...

Comment 9

[Asa Dotzler [:asa]]

updating to new owner. sorry for the spam.

Comment 10

[Matthew T (active 1999-2002)]

Ok, Ben expressed an interest in fixing this bug. So I fiddled around for a 
while, and this is the best I could come up with. It's as short as I can make 
it, without being either obscure or possibly inaccurate.

+-----------------------------------------------------------+
| Mozilla ::::::::::::::::::::::::::::::::::::::::::::::::::|
+-----------------------------------------------------------+
|  .   Your Windows settings, for file types and protocols  |
| /!\  handled by Mozilla, have changed. Do you want to     |
| """  restore the Windows settings to match those in       |
|      Mozilla Preferences?                                 |
|                                                           |
|                [[ Restore ]] [ Don't Restore ] [ Cancel ] |
+-----------------------------------------------------------+

Comment 11

[Matthew T (active 1999-2002)]

*** Bug 81854 has been marked as a duplicate of this bug. ***

Comment 12

[Matthew T (active 1999-2002)]

Following comments in bug 81854, `Cancel' above should be `Exit'.

Comment 13

[sairuh (rarely reading bugmail)]

moving Windows Integration [formerly Desktop Integration] bugs to PaulW as qa
contact.

Comment 14

[Ben Goodger (use ben at mozilla dot org for email)]

Yes, let's do this soon, for the love of all that is good and decent. 

Comment 15

[Ben Goodger (use ben at mozilla dot org for email)]

Over to Bill who handles all the Windows Integration stuff. 

Comment 16

[:deanis74]

"Your Windows settings, for file types and protocols handled by Mozilla, have
changed."

You don't need the commas.  It reads jerkily with them in, and "for file types
and protocols handled by Mozilla" is pretty essential information.

I also agree with David, toast the Cancel button.  A lot of times a
yes/no/cancel dialog can prove to be very confusing.

How about this:

"Your Windows settings for file types and protocols that Mozilla handles have
changed.  Do you want to restore these settings to match those in your Mozilla
preferences?"

Comment 17

[:deanis74]

Or better yet, "The Windows settings..."

Comment 18

[Bill Law]

Resetting target milestone for all "window integration" bugs to mozilla0.9.8.  
I'm working on performance and won't get to that till next milestone.

Comment 19

[Bill Law]

Not getting to this, either.

Comment 20

[Bill Law]

This was fixed, for all intents and purposes, by way of another bug.  There is 
only one dialog and it simply says/asks: "=%S is not currently set as your 
default browser. Would you like to make it your default browser?".  That's not 
quite the same as saying this is "fixed," but I don't want to say this 
is "invalid," either.  We need a "moot" resolution code.

Comment 21

[Matthew Wilson]

As far as I can see, it is not fixed. There are three options on that dialog,
Yes, No, and Cancel. Cancel and No seem to have the same effect.

Reopening.

Comment 22

[Bill Law]

"No" and "Cancel" are different.  That difference may not be obvious enough in 
some cases (the main difference is that when you see this dialog the first time 
after installation, "no" turns off all preferences and "cancel" just defers the 
decision till the next time you run).

Perhaps we need to focus this bug, then.  Do you want the "Cancel" choice to go 
away entirely?  Go away when the effect of cancel vs. no is less subtle (other 
than install time)?  I can see just removing the choice entirely.

Comment 23

[Matthew Wilson]

I don't have a strong opinion on this - Cancel can either go away as an option,
or do something appropriate (like browser exit).

Comment 24

[timeless]

can you change Cancel to Remind?

Comment 25

[Matthew Wilson]

timeless:
I don't think that "Remind" is a better description than "Cancel".

If you've installed Mozilla is your default browser, and then later changed your
Windows settings to make it not the default browser, then Cancel is the same as
No (as far as I can tell), meaning "start up the browser without changing my
Windows settings". (Or am I wrong?)

Bill:
> "No" and "Cancel" are different.  That difference may not be obvious enough in 
> some cases (the main difference is that when you see this dialog the first time 
> after installation, "no" turns off all preferences

What do you mean by "turns off all preferences"? Does it change Windows settings?

Comment 26

[Bill Law]

"remind" doesn't make sense if the user has unchecked the "check next time" box.

re: Does it change Windows settings?

No, Pressing "no" and "cancel" will never cause the Windows registry to change
(well almost, we do twiddle some bits in our own registry entries that tell us
that you've seen the alert, unchecked the box, etc.).

I think removing Cancel is best.  It doesn't really do anything except the first
time you see the dialog (after install).  That's not a high priority, however,
so setting target milestone to 1.0.1.

Comment 27

[Terri Preston]

Changing qa contact to me, as I am working on these now ;-)

Comment 28

[Alex Bishop]

*** Bug 140021 has been marked as a duplicate of this bug. ***

Comment 29

[Ere Maijala (slow)]

I suggest the style described in bug 128071. Most people do not know/guess the
difference between No and Cancel, but a checkbox makes it all clear and
consistent with the rest of the dialogs that have a "do not ask/display/whatever
this anymore" checkbox.

Comment 30

[Terri Preston]

qa contact windows integration-> pmac

Comment 31

[Sébastien Delahaye]

*** Bug 199553 has been marked as a duplicate of this bug. ***

Comment 32

[Pauli "suokko" Nieminen]

Attachment: Patch for dialog to show only nesessery buttons.

Requesting for code rewiev. (Beta patch, tested that it works (in win xp) but
not sure if interface changes are OK.)

This patch main target is to make 3rd button shown only in first startup when
there isn't allready register entries for default browser settings.

2nd change is that It shows check box even in first startup that user may
choose that he don't want to see this dialog any more if choose "No"

3rd Replace text in cancel button with "&Set this later"

PS. This was just learning tro use cvs diff and makeing patches for mozilla. I
hope someone will tell me if there anything which should be done differentaly.
Any codeing stuff which I should learn?

Comment 33

[Ere Maijala (slow)]

I still support the dialog style described in bug 128071 although a longer
explanation might be better.

Comment 34

[Pauli "suokko" Nieminen]

Comment on attachment 128767 [details] [diff] [review]
Patch for dialog to show only nesessery buttons.

Index: nsWindowsHooks.cpp
===================================================================
RCS file: /cvsroot/mozilla/xpfe/components/winhooks/nsWindowsHooks.cpp,v
retrieving revision 1.46
diff -u -r1.46 nsWindowsHooks.cpp
--- nsWindowsHooks.cpp	3 Jun 2003 20:54:18 -0000	1.46
+++ nsWindowsHooks.cpp	29 Jul 2003 09:52:36 -0000
@@ -425,7 +425,7 @@
		     rv = bundleService->CreateBundle(
"chrome://global/locale/brand.properties",
						       getter_AddRefs(
brandBundle ) );
		     if ( NS_SUCCEEDED( rv ) && bundle && brandBundle ) {
-			 nsXPIDLString text, label, shortName;
+			 nsXPIDLString text, label, shortName,later;
			 if ( NS_SUCCEEDED( ( rv =
brandBundle->GetStringFromName( NS_LITERAL_STRING( "brandShortName" ).get(), 
					      getter_Copies( shortName ) ) ) )
) {
			     const PRUnichar* formatStrings[] = {
shortName.get() };
@@ -433,29 +433,47 @@
						   formatStrings, 1,
getter_Copies( text ) ) ) )
				   &&
				   NS_SUCCEEDED( ( rv =
bundle->GetStringFromName( NS_LITERAL_STRING( "checkBoxLabel" ).get(),
-									       
   getter_Copies( label ) ) ) ) ) {
+									       
   getter_Copies( label ) ) ) ) 
+				   &&
+				   NS_SUCCEEDED( ( rv =
bundle->GetStringFromName( NS_LITERAL_STRING( "laterButtonLabel" ).get(),
+									       
   getter_Copies( later ) ) ) ) ) {
				 // Got the text, now show dialog.
				 PRBool  showDialog = settings->mShowDialog;
				 PRInt32 dlgResult  = -1;
				 // No checkbox for initial display.
-				 const PRUnichar *labelArg = 0;
+				 const PRUnichar *laterarg = 0;
+								PRUint32
buttons;
+
+								// To create
buttons on the fly depending on what are needed.
				 if ( settings->mHaveBeenSet ) {
				     // Subsequent display uses label string.
-				     labelArg = label;
-				 }
+									buttons
= (nsIPromptService::BUTTON_TITLE_YES * nsIPromptService::BUTTON_POS_0) +
+						  
(nsIPromptService::BUTTON_TITLE_NO * nsIPromptService::BUTTON_POS_1);
+				 }
+								else
+								{
+									buttons
= (nsIPromptService::BUTTON_TITLE_YES * nsIPromptService::BUTTON_POS_0) +
+									       
		   (nsIPromptService::BUTTON_TITLE_IS_STRING *
nsIPromptService::BUTTON_POS_1) +
+						   
(nsIPromptService::BUTTON_TITLE_NO * nsIPromptService::BUTTON_POS_2);
+								       
laterarg = later;
+								}
+
				 // Note that the buttons need to be passed in
this order:
				 //    o Yes
				 //    o Cancel
				 //    o No
				 rv = promptService->ConfirmEx(aParent,
shortName, text,
-							      
(nsIPromptService::BUTTON_TITLE_YES * nsIPromptService::BUTTON_POS_0) +
-							      
(nsIPromptService::BUTTON_TITLE_CANCEL * nsIPromptService::BUTTON_POS_1) +
-							      
(nsIPromptService::BUTTON_TITLE_NO * nsIPromptService::BUTTON_POS_2),
-							       nsnull, nsnull,
nsnull, labelArg, &showDialog, &dlgResult);
+							       buttons,
+							       nsnull,
laterarg, nsnull, label, &showDialog, &dlgResult);

				 if ( NS_SUCCEEDED( rv ) ) {
				     // Dialog was shown
-				     *_retval = PR_TRUE; 
+				     *_retval = PR_TRUE;
+									// To
correct return value when have only 2 buttons
+									if (
settings->mHaveBeenSet && dlgResult == 1)
+									{
+									       
dlgResult = 2;
+									}

				     // Did they say go ahead?
				     switch ( dlgResult ) {
Index: locale/en-US/nsWindowsHooks.properties
===================================================================
RCS file:
/cvsroot/mozilla/xpfe/components/winhooks/locale/en-US/nsWindowsHooks.propertie
s,v
retrieving revision 1.4
diff -u -r1.4 nsWindowsHooks.properties
--- locale/en-US/nsWindowsHooks.properties	13 Feb 2002 02:57:29 -0000     
1.4
+++ locale/en-US/nsWindowsHooks.properties	29 Jul 2003 09:52:37 -0000
@@ -1,6 +1,7 @@
 yesButtonLabel=Yes
 noButtonLabel=No
 cancelButtonLabel=Cancel
+laterButtonLabel=&Set this later
 checkBoxLabel=Check at startup next time, too.
 promptText=%S is not currently set as your default browser. Would you like to
make it your default browser?
 prefsLabel=Pr&eferences

Comment 35

[Mike Connor [:mconnor]]

taking.  The No vs. Cancel button is really redundant, Yes/No is all that's
needed, as Bill Law noted in comment 26.  Remind Me Later is possible, but that
would have to be replacing the checkbox for "show this next time too" which
would break from established convention on Windows (Opera/IE use the checkbox,
NS/Mozilla has traditionally done the same).

Comment 36

[Mike Connor [:mconnor]]

Attachment: Make this into a sane Yes/No dialog

Comment 37

[[e-mail]]

OK, so there are two cases where Cancel might be needed: on the first install,
Cancel doesn't clear the default associations, whereas No does; also Cancel
doesn't save the checkbox but again No does. Now AFAIK if IE isn't your default
browser, and you start it, and you say No, but leave the checkbox on, then it
will prompt again the next time, but Mozilla won't, right?

Comment 38

[Mike Connor [:mconnor]]

Comment on attachment 138609 [details] [diff] [review]
Make this into a sane Yes/No dialog

Neil, should we follow the convention followed by IE/Opera that's basically
Yes/No and always has a show again checkbox visible?  We have this if the
dialog comes back, i.e. if you choose yes, then choose another browser, the
checkbox is shown on all subsequent prompts.  Its the simplest option and least
likely to confuse users.  As long as the box is checked, it will be seen on
every subsequent startup, which matches IE's behaviour, except for the poorly
defined Cancel button.

As an alternative, we could have a first run that doesn't show the checkbox,
and have the dialog appear a second time with the checkbox, at which point the
dialog would allow you to choose to permanently dismiss it by unchecking the
box.

At present, choosing no simply records the value of the checkbox, and sets the
registry entry that indicates we've seen the dialog already (which we don't
need if we show the checkbox every time).  That's borne out by the code and by
comment 26.  The only flaw I see in the current patch is that on the first run,
choosing No does not give the option to show the dialog again (which is the
behaviour currently as well).  We still need to be able to do this

Comment 39

[Mike Connor [:mconnor]]

Attachment: better patch

Comment 40

[Mike Connor [:mconnor]]

Comment on attachment 138682 [details] [diff] [review]
better patch

first appearance gives yes/no option, no checkbox visible.  Choosing No is not
a final decision in this case, and second startup of app yields the same
message, but with a checkbox for Show this next time, too.

Its quite trivial to make it appear that way for all iterations, however I like
this method as it gives the user a second chance to make the choice, AFTER they
have gone ahead and used the product.  From the second appearance and onward,
removing the checkbox suppresses the dialog unless re-enabled in advanced
prefs.

Comment 41

[Ere Maijala (slow)]

I personally hate it when I have to do something again because a program doesn't
give me all the choices the first time. I'd rather have the checkbox always
visible. 

Comment 42

[[e-mail]]

So, is IE's No the equivalent of Mozilla's Cancel (except that Mozilla always
asks next time if you cancel)?

Comment 43

[Mike Connor [:mconnor]]

From a user perspective, it does both No and Cancel.  If you check the box, it
doesn't show again (No), if you don't check the box, it keeps coming back
(Cancel).  All No does here is some of the first time stuff re: setting which
filetypes it should take if/when we say yes (saving this in registry prefs), and
remembers the showDialog pref.  Cancel just does nothing and the dialog does the
first time prompt routine all over again.

Comment 44

[[e-mail]]

The problem is we've got two ways of not checking for associations...

Comment 45

[Mike Connor [:mconnor]]

Neil, when you say we have two ways of not checking for associations, what do
you mean?

Comment 46

[[e-mail]]

Well... we've got two ways of dealing with those users who don't want to
associate Mozilla with everything in sight... you can turn off the check, or you
can check none of the possible associations...

Comment 47

[Mike Cowperthwaite]

*** Bug 129204 has been marked as a duplicate of this bug. ***

Comment 48

[Robert Kaiser]

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

Comment 49

[Robert Kaiser]

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

Comment 50

[Robert Kaiser]

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

Comment 51

[Robert Kaiser]

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

Comment 52

[Robert Kaiser]

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

Comment 53

[Robert Kaiser]

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

Comment 54

[[e-mail]]

This was fixed by the patch in bug 380347.