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.

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

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.

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]

[really giving to Claudius this time]

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

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.

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

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

updating to new owner. sorry for the spam.

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 ] | +-----------------------------------------------------------+

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

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

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

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

Over to Bill who handles all the Windows Integration stuff.

"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?"

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

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.

Not getting to this, either.

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.

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.

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

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

can you change Cancel to Remind?

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?

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

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

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

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.

qa contact windows integration-> pmac

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

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?

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

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

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

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

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.

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

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.

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

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

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

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

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

This was fixed by the patch in bug 380347.