27187 - need to support making Mozilla the default browser

Status: VERIFIED FIXED

(SeaMonkey :: Installer, defect, P1)

Description

[ekrock's old account (dead)]

When you install Seamonkey, it already makes itself (with user consent) the 
default handler for .htm files, etc.  It should make itself the default handler 
for XML files as well.

(A friend observed to me by email [below] that IE registers itself as the 
default handler for XML files, so we need to do the same to avoid having 
clicking an XML file at the OS level fire off IE instead of Mozilla.)

From: "Husted, Robert" <[e-mail]> 
  To: "'Krock, Eric'" <[e-mail]> 

  Eric,
   
      No joke.  Bring up an XML document in Navigator -- if you pick "open"
  the browser spawns MSIE to display the XML document!  Happens on every
  machine at Qwest.  Is this a Microsoft trojan horse or a new feature of
  Navigator?

Comment 1

[Sean Su]

This needs to be done by mozilla.exe because it already does (or will do) 
checking for other file extensions (like .html, htm, .js,...) and alerts the 
user of the associations.  However, I don't know who this would belong to.

Comment 2

[Sean Su]

reassigning to Bill Law.  He said he has to do something like this in future 
already.

Comment 3

[don]

Bill, should we really own this bug?

Comment 4

[Bill Law]

Sure, why not.  I think this falls under the "win98 integration" bug I've had 
for some time.

I think maybe something should also happen at install time.  If, as stated, 
Seamonkey is made the default handler for .html, then it's not mozilla.exe 
that's doing that (to my knowledge). 

Comment 5

[leger]

Putting on [nsbeta2+] radar for beta2 fix.

Comment 6

[Sean Su]

reassigning this bug to myself after talking with Bill Law.

Comment 7

[Sean Su]

I'm waiting on Bill to provide a standalone version of this routines used to set 
this up.  Once he is done, I can just link his code with mine so we only have 
one set of code to deal with.

Comment 8

[Daniel Veditz [:dveditz]]

This bug appears to have morphed. Originally it described while already running 
Mozilla having XML docs opened by the windows registered handler for that type. 
Clicking on an HTML document on the desktop does not open mozilla so clicking 
on an XML doc wouldn't either.

This appears to have morphed into a bug for having the installer set Seamonkey  
up as the default handler for HTML and other standard types, and apparently 
Bill and Sean agreed this code would live in Mozilla and be triggered by the 
existing "-installer" command line. Reassigning to law.

Comment 9

[don]

Removed nsbeta2+ for reconsideration.  Don't think we need this for PR2. 
Marking for beta 3 consideration (michaell wrote this)

Comment 10

[verah (gone)]

Nav triage team: [nsbeta3+]

Comment 11

[Phil Peterson]

PDT agrees P2

Comment 12

[timeless]

Is there a separate bug for the other integration?

Comment 13

[don]

Move to RTM.

Comment 14

[johng]

nav triage team:
law has a patch, so keeping rtm+

Comment 15

[Phil Peterson]

PDT marking [rtm need info] since no code reviews are listed.

Comment 16

[Zach Lipton [:zach]]

bumping to M18, M17 is gone...

Comment 17

[don]

Fix in hand.

Comment 18

[Bill Law]

Changing summary to state more precisely the nature of the problem.  We need to
add support for installing Mozilla as the "default browser" on Windows.  This is
basically updating the summary to match the "morphing" that occured, and which
Dan Veditz described very well a while back.

Comment 19

[Bill Law]

Attachment: Proposed fix

Comment 20

[Bill Law]

Attachment: New jar.mn file for mozilla/xpfe/components/winhooks directory

Comment 21

[Bill Law]

Attachment: New .properties file with text for dialogs

Comment 22

[Bill Law]

Attachment: Additional patch to prefwindow to add "Show dialog" checkbox to pref-winhooks

Comment 23

[don]

Changing severity to critical and priority to P1.  We're screwed if this isn't
in the Windows RTM bits.

Comment 24

[Sean Su]

adding msanz to the CC: list because there's new strings to localize.
adding Todd to the CC: list because we need marking input on the issue of always 
check the registry on launch by the installer.

Comment 25

[Daniel Veditz [:dveditz]]

ssu: Why would the installer have to do any checking? We always launch Mozilla 
at the end so if Mozilla does the checking we should be covered.

Comment 26

[don]

Upgrading to P1 again.  Weird ...

Adding to cc ...

Comment 27

[Sean Su]

Law's code is not hooked up to the -installer flag right now, so it would obey 
the preference settings from a previous install (meaning that if the user 
disabled his checking mechanism from a previous install, it would obey that).

I've asked marketing to decide if Law's code should be hooked up to the 
-installer flag and ignore the preference setting from a previous install so 
that his code always performs a check at this instance only.

Comment 28

[Todd Pringle]

After discussing with Bij, our take from the marketing perspective is that we
should tie this to install so that this dialogue comes up if the client is
reinstalled (and all the defaults are not set already).

- Most users (hopefully) won't be reinstalling anyway.  It's a small
inconvenience for those who do, but only comes up if they didn't set these
preferences on the first install anyway (right?).

- Some users may click "don't show me this again" because they don't really
understand what they're being asked, but after using the product and having IE
come up when they look at certain file types (when they're expecting N6), then
this dialogue on a reinstall may be more clear and they may be more likely to
enter N6 as the default.

Comment 29

[msanz]

approving change, but please, fix it asap (no later than next week)

Comment 30

[Bill Law]

Attachment: initial prompt dialog (shown when app is first run)

Comment 31

[Bill Law]

Attachment: subsequent dialog (shown when windows registry is out of synch with Desktop Integration prefs)

Comment 32

[Bill Law]

Attachment: Updated patch with "-installer" trigger

Comment 33

[Bill Law]

I've attached .jpg images of the initial and subsequent alerts.  German has
already suggested that the button labels should be more explicit (e.g., "Update
registry" instead of "Yes").

Those are trivial .properties file changes; just let me know.

I've also updated the code (and attached a new patch) to look for "-installer"
and have that override the user having turned off the nag dialog.

There is also the new item on the pref panel.  It's just a checkbox with the
label that's in the .properties file.  I can post a screen shot if anybody
really wants to see it.

Comment 34

[Sean Su]

r=ssu
just need a sr= now.

Comment 35

[Scott Collins]

This is a big patch and I'm going over it, but a thorough review of a patch this
size will take me some time ... a couple of hours at least (interleaved with the
sheriffing I'm doing right now).  And don't say |NS_WITH_SERVICE|.  Do what it
does directly instead

  nsCOMPtr<nsICommonDialogs> commonDlgService(do_GetService(commonDlgCID,&rv));

etc.

Comment 36

[timeless]

Hi law, thanks for working on this.
I have some objections to the way mozilla/netscape and some of its competitors  
do this ~May I please take over your computer and trample your registry?~  
prompts. If it isn't too much to ask for mozilla1.0 and netscape6.1 or 6.5 (6.1 
is not 6.01) could we add details or twisty [twisty on macos, details seems 
prefered by ms on windows] that gives a list of what things mozilla/netscape 
intend to capture and who currently owns them. {cc mpt}

I like to know that my system is _mine_.  If an app gives me a list of things 
it's about to capture and I agree then I'll say ok. However, if the app just 
says ~may I practice voodoo all over your system?~, I get very anxious and say 
no. This is not because the app is going to do something evil, but because I 
don't know what it's really going to do.

Also, on especially under windows nt I think you can have systemwide and 
userspecific associations. [I'm administrator, so for me I only have one file 
associated per user.] If the user wants to associate netscape w/ these items 
and is not allowed to do a system wide change, would our system [now or in the 
future] offer to make the change per [current] user? And in the case that an 
administrator decides to test something could we actually give the user the 
option of making the change for the machine or the account? {cc david}

Comment 37

[Matthew T (active 1999-2002)]

If these file association options are per-user prefs, they should be synced with 
the `Applications' prefs panel. And if they're global prefs, they shouldn't be in 
the prefs dialog at all -- what happens if one user profile has one set of 
`Desktop Integration' prefs, and another user has another set? Bedlam.

In the long term, what would be really nice is a separate XUL program which 
allows the user to control exactly how and where they want Mozilla -- where they 
want shortcuts for each component to go (Desktop/Start Menu/QuickLaunch bar/etc), 
whether Mozilla should be launched if I type an URL into Start>Run, what file 
types Mozilla should be associated with, etc etc etc.

But for the short term, wording fixes for those dialogs (for starters, `Desktop 
Integration' sounds like a combined desk and filing cabinet) ...

Comment 38

[Matthew T (active 1999-2002)]

Attachment: Suggested replacement .properties file

Comment 39

[timeless]

"Windows Settings preferences"
ARGH. Settings = preferences.

Please use something else. Otherwise the .properties looks ok (I have no 
context, please consider diff -u, you know the people on irc who can help you w/ 
that)

Comment 40

[Bill Law]

re:  [e-mail] 2000-10-07 21:28

Your suggestions sound reasonable.  We may wish to not overload the user with
information when the dialog is shown but instead provide a button to take them
to the prefs panel.  That panel could be expanded to show the current
application handling file types, internet shortcuts, etc.

Your questions about systemwide vs. per-account settings are good ones.  I'm not
sure how much flexibility we have here.  See my additional comments below.

re: Matthew Thomas (mpt) 2000-10-08 02:03

The settings control two (almost) completely independent things: what
preferences the current profile specifies versus the settings in the window
registry.  There can be multiple profiles per Windows-user, with different
settings, and different Windows-users (with different registry settings) per
profile.

We try to do the best we can with this situation.  This is Windows we're talking
about, so "bedlam" is perhaps the norm.

As far as the term "desktop integration" is concerned; I'm not sure a "combined
desktop and filing system" isn't actually a reasonable metaphor.  Not to say
that "Windows Settings" isn't better.  Of course, that sounds like what the
Start->Settings menu deals with, and it doesn't look at all like that.

Fortunately, this is easily remedied.  I don't much care one way or the other.

Comment 41

[johng]

All we need now is a super review.   This is essential - very few bugs more
directly effect market share, usage and revenue then this one.

Comment 42

[Scott Collins]

At last I've gone over this patch in detail with Bill Law, and seen it function
in all of the important cases.  Here's what Bill and I decided it needed to get
an sr=:

  - prefer |do_GetService| over the obfuscating |NS_WITH_SERVICE| macro
  - prefer direct-initialization over copy-initialization
  - prefer |NS_LITERAL_STRING("...")| over |NS_ConvertASCIItoUCS2("...")|
  - prefer |nsXPIDLCString| over managing string deallocation by hand
  - |already| requires a little too much consideration before the meaning
      becomes obvious ... rename to something that holds our hand a little more
      like |alreadyCheckedSettings|
  - a small nit: "sez" --> "says" in the user comments

Bill will attach a new patch with these small changes shortly; I will sr= at
that time.  These changes look good to me, this code executes rarely and at very
well defined times (once per run, at launch time) and has a very low risk
fallback position as well in that the one line change to call it can be easily
backed out if necessary, leaving this code un-used.  I give this code a strong
vote of confidence.

Comment 43

[ekrock's old account (dead)]

Strongly endorse taking the final patch. We're shooting ourselves in the foot if 
we don't enable ourselves to be made the default browser. (Duh!) We have to 
fight the competition for default status at every opportunity to sustain and 
grow market share.

Comment 44

[msanz]

can we get this fixed today at most? UI change was approved with a limit of
today. I know we don't have much choice with this bug, but we need this in the
branch immediately, please!

Comment 45

[Bill Law]

Attachment: Patch with scc's suggested changes

Comment 46

[Scott Collins]

Looks terrific.  sr=scc.

Comment 47

[don]

Great!  Let's land this puppy.

Comment 48

[Bill Law]

Fix checked into the trunk.

Comment 49

[Phil Peterson]

rtm++. Crossing fingers and hoping good code reviews are enough here.

Comment 50

[Bill Law]

Fix in on branch as of late friday night.

Comment 51

[Grace Bush]

verified on build 2000101609MN6

Comment 52

[Grace Bush]

verified on trunk 2000111706