need to support making Mozilla the default browser

VERIFIED FIXED in M18

Status

SeaMonkey
Installer
P1
critical
VERIFIED FIXED
19 years ago
14 years ago

People

(Reporter: ekrock's old account (dead), Assigned: Bill Law)

Tracking

Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [FEATURE][nsbeta3-][medium][PDTP2][rtm++]Fix in hand, reviewed and approved)

Attachments

(9 attachments)

(Reporter)

Description

19 years ago
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" <Robert.Husted@qwest.com> 
  To: "'Krock, Eric'" <ekrock@netscape.com> 

  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

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

19 years ago
reassigning to Bill Law.  He said he has to do something like this in future 
already.
Assignee: ssu → law

Comment 3

18 years ago
Bill, should we really own this bug?
Priority: P3 → P2
Target Milestone: M16
(Assignee)

Comment 4

18 years ago
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). 
Status: NEW → ASSIGNED

Updated

18 years ago
Keywords: nsbeta2
Whiteboard: [FEATURE]
Target Milestone: M16 → M17

Comment 5

18 years ago
Putting on [nsbeta2+] radar for beta2 fix.
Whiteboard: [FEATURE] → [nsbeta2+] [FEATURE]

Comment 6

18 years ago
reassigning this bug to myself after talking with Bill Law.
Assignee: law → ssu
Status: ASSIGNED → NEW

Comment 7

18 years ago
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.
Status: NEW → ASSIGNED
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.
Assignee: ssu → law
Status: ASSIGNED → NEW
Summary: installer needs to make Seamonkey the default handler for XML files → need to make Seamonkey the default handler for [*]ML files

Comment 9

18 years ago
Removed nsbeta2+ for reconsideration.  Don't think we need this for PR2. 
Marking for beta 3 consideration (michaell wrote this)
Keywords: nsbeta2 → nsbeta3
Whiteboard: [nsbeta2+] [FEATURE] → [FEATURE]

Comment 10

18 years ago
Nav triage team: [nsbeta3+]
Whiteboard: [FEATURE] → [FEATURE][nsbeta3+]
(Assignee)

Updated

18 years ago
Whiteboard: [FEATURE][nsbeta3+] → [FEATURE][nsbeta3+][medium]

Comment 11

18 years ago
PDT agrees P2
Whiteboard: [FEATURE][nsbeta3+][medium] → [FEATURE][nsbeta3+][medium][PDTP2]

Comment 12

18 years ago
Is there a separate bug for the other integration?

Comment 13

18 years ago
Move to RTM.
Keywords: rtm
Whiteboard: [FEATURE][nsbeta3+][medium][PDTP2] → [FEATURE][nsbeta3-][medium][PDTP2][rtm+]

Updated

18 years ago
Blocks: 54197

Comment 14

18 years ago
nav triage team:
law has a patch, so keeping rtm+
Keywords: patch

Comment 15

18 years ago
PDT marking [rtm need info] since no code reviews are listed.
Whiteboard: [FEATURE][nsbeta3-][medium][PDTP2][rtm+] → [FEATURE][nsbeta3-][medium][PDTP2][rtm need info]

Comment 16

18 years ago
bumping to M18, M17 is gone...
Target Milestone: M17 → M18

Comment 17

18 years ago
Fix in hand.
Whiteboard: [FEATURE][nsbeta3-][medium][PDTP2][rtm need info] → [FEATURE][nsbeta3-][medium][PDTP2][rtm need info]Fix in hand, being reviewed
(Assignee)

Comment 18

18 years ago
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.
Summary: need to make Seamonkey the default handler for [*]ML files → need to support making Mozilla the default browser
(Assignee)

Comment 19

18 years ago
Created attachment 16291 [details] [diff] [review]
Proposed fix
(Assignee)

Comment 20

18 years ago
Created attachment 16292 [details]
New jar.mn file for mozilla/xpfe/components/winhooks directory
(Assignee)

Comment 21

18 years ago
Created attachment 16293 [details]
New .properties file with text for dialogs
(Assignee)

Comment 22

18 years ago
Created attachment 16294 [details] [diff] [review]
Additional patch to prefwindow to add "Show dialog" checkbox to pref-winhooks

Comment 23

18 years ago
Changing severity to critical and priority to P1.  We're screwed if this isn't
in the Windows RTM bits.
Severity: enhancement → critical
Priority: P2 → P1

Comment 24

18 years ago
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.
Severity: critical → enhancement
Priority: P1 → P2
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.
Severity: enhancement → critical

Comment 26

18 years ago
Upgrading to P1 again.  Weird ...

Adding to cc ...
Priority: P2 → P1

Comment 27

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

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

18 years ago
approving change, but please, fix it asap (no later than next week)
(Assignee)

Comment 30

18 years ago
Created attachment 16363 [details]
initial prompt dialog (shown when app is first run)
(Assignee)

Comment 31

18 years ago
Created attachment 16364 [details]
subsequent dialog (shown when windows registry is out of synch with Desktop Integration prefs)
(Assignee)

Comment 32

18 years ago
Created attachment 16366 [details] [diff] [review]
Updated patch with "-installer" trigger
(Assignee)

Comment 33

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

18 years ago
r=ssu
just need a sr= now.

Comment 35

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

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

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

18 years ago
Created attachment 16467 [details]
Suggested replacement .properties file

Comment 39

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

Comment 40

18 years ago
re:  timeless@bemail.org 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

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

Updated

18 years ago
Blocks: 44714

Comment 42

18 years ago
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.
(Reporter)

Comment 43

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

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

Comment 45

18 years ago
Created attachment 17041 [details] [diff] [review]
Patch with scc's suggested changes

Comment 46

18 years ago
Looks terrific.  sr=scc.

Comment 47

18 years ago
Great!  Let's land this puppy.
Whiteboard: [FEATURE][nsbeta3-][medium][PDTP2][rtm need info]Fix in hand, being reviewed → [FEATURE][nsbeta3-][medium][PDTP2][rtm+]Fix in hand, reviewed and approved
(Assignee)

Comment 48

18 years ago
Fix checked into the trunk.

Comment 49

18 years ago
rtm++. Crossing fingers and hoping good code reviews are enough here.
Whiteboard: [FEATURE][nsbeta3-][medium][PDTP2][rtm+]Fix in hand, reviewed and approved → [FEATURE][nsbeta3-][medium][PDTP2][rtm++]Fix in hand, reviewed and approved
(Assignee)

Comment 50

18 years ago
Fix in on branch as of late friday night.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 51

18 years ago
verified on build 2000101609MN6
Keywords: vtrunk

Comment 52

18 years ago
verified on trunk 2000111706
Status: RESOLVED → VERIFIED
Keywords: vtrunk
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.