97813 - Need to Properly integrate Navigator in the Windows XP Start Menu

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P1)

Description

[Sean Su]

In the Windows XP start menu, there is a default section at the top of the
lefthand pane (MSFT calls it the "pinned" area) that features your "default"
browser and mail application.

Currently, we properly register Navigator and Mail in such a way that we are a
configurable choice for this placement in the Start Menu, but a user has to go
in and specify us/customize their Start Menu in order for us to appear in this area.

For 0.9.4, we need to:

Place Navigator in this area upon install WHEN a user says "Yes" to the
desktop integration dialog asking them if they want Netscape to handle internet
file types.

I believe Sean has already investigated this and Montse knows where the MSFT
documentation on how to do this is.  It is critical that we get this for 0.9.4.

This bug is only for the browser.  The Mail integration part into Windows XP's
Start menu is bug 95724.

Comment 1

[Ryan Pertusio]

Yep, this would be good to get into 0.9.4   .. maybe some keywords would be
appropriate in this case?

(an unrelated comment: we should soon get "Windows XP" on the OS list for
Bugzilla..  I'm seeing a gradual increase of bugs relating to winXP)

Comment 2

[Ryan Pertusio]

Yep, this would be good to get into 0.9.4   .. maybe some keywords would be
appropriate in this case?

(an unrelated comment: we should soon get "Windows XP" on the OS list for
Bugzilla..  I'm seeing a gradual increase of bugs relating to winXP)

Comment 3

[Todd Pringle]

Adding nsBranch keyword and ccing trudelle.  

Comment 4

[Bill Law]

Targetting for 0.9.5.

Comment 5

[Bill Law]

I've installed XP and have been playing with it to see how this Start menu
business works.

I think I understand how it works, but I have some questions about how to have
Mozilla/Netscape6.x deal with this:

1. Does the installer "register" NS6.1 under
[HKLM\Software\Clients\StartMenuInternet]?  I see an entry under there for NS6.1
(and we show up in the dropdown if I go to Configure... the Start menu).

2. The extra step required to actually make us the "start menu internet
application" is to set [HKCU\Software\Clients\StartMenuInternet] to point to our
subkey under [HKLM\Software\Clients\StartMenuInternet], right?

3. That key seems to be "netscp6.exe".  Can I code to that and rely on it being
accurate?

4. What about Mozilla?  I can easily use the actual .exe name (rather than
"netscp6.exe" hardcoded).  But who will put Mozilla under
[HKLM\Software\Clients\StartMenuInternet]?  If we do that outside the installer,
then that code will have to avoid doing it for netscp6 (presuming the installer
is doing it currently).  Maybe the best strategy would be for me to check
whether the client is already "registered" and skip that step if it is?  Or does
the Mozilla installer take care of that?

5. Should I add another check-box to the Advanced|System prefs panel asking "Do
you want Mozilla/Netscape to be the default Start Menu Internet Application?" or
just go ahead and do that if they've asked us to handle http?  I'd rather do the
latter because the checkbox would be
XP-only and a pain to implement.

Here's the link to Microsoft's documentation on this feature:
<http://support.microsoft.com/support/kb/articles/Q297/8/78.ASP>

Comment 6

[Sean Su]

The installer currently only adds the navigator to the list of "possible" 
default browsers.  It stops short of making it show up as the default in the 
Start menu.  So to answer you questions:

1) yes, that's correct.
2) yes, correct as well.
3) I wouldn't count on that.
4) The installer currently sets N6.1 (not mozilla) to the list of available 
browsers.  I rather have the installer not do this and instead have the same 
browser code that already performs Windows Integration do this as well under 
WinXP.  This way it's centralized and much cleaner, and it would also work for 
mozilla.
5) I don't think there's a need to add another checkbox to the prefs.  I would 
suggest that if it's XP (and it's not set yet), and the user chooses to set 
navigator as the default http handler for the system/current user, to 
actually do the appropriate registry changes to have us show up in the Start 
menu.

I would also suggest to make sure that navigator is listed in the list of 
available default browsers regardless if the user wants us to be the default or 
not.  This is because being default and being in the list of available defaults 
are not really dependent on each other (for our purpose).

As always, having a way to restore the previous default is a very good thing.  
I'll work with Syd to make sure the uninstaller is able to also restore the 
previous settings.

Comment 7

[Bill Law]

Man, this WindowsXP is really clever.

I coded up a patch for this bug that sets
HKCU/Software/Clients/StartMenuInternet when the user sets up Mozilla to handle
http.  This includes a test for whether we're registered under
HKLM/Software/Clients/StartMenuInternet.  I haven't yet added the code that
registers under that key.  So I figured that the test would fail, since we
aren't registered yet.

But it seems mozilla.exe *is* registered, without us having to do anything. 
WindowsXP seems to detect whether we've taken over the registry entries for http
and if so, it automagically registers us as an "Internet application."

Using regmon, I can see explorer.exe setting all the registry keys to register
mozilla.exe.

I also observe that it puts MOZILLA.EXE in
HKLM\Software\Clients\StartMenuInternet.  For some reason,
HKCU\Software\Clients\StartMenuInternet is not set on my machine.  Explorer
seems to then fall back to the HKLM setting.  So Mozilla ends up being my
"default start menu internet app" without having to do anything.

All this is very confusing to me.  I'm going to have to reset my machine and go
through this exercise again, observing how this all plays out before I can say
for sure how this is supposed to work.

Comment 8

[timeless]

Law: generally registry behavior is to check HKCU for a value and fall back to 
HKLM if none is found.

However if you want to see an instance where ms messes up on that behavior, set 
HKLM'shell' to explorer.exe and HKCU'shell' to cmd.exe, logon, run explorer. 
Then change both to HKLM'shell' to cmd.exe (vary HKCU if you like), logon, run 
explorer. [this is explorer being a tad bit drunk]

Out of curiosity, are you admin when you did these tests? because you should 
definitely test fresh twice, once as admin and once as mortal. When you're 
mortal, your changes should land in HKCU and the system shouldn't do you the 
'favor' of setting anything in HKLM.

Comment 9

[Jaime Rodriguez, Jr.]

Law/Peter - Is this really needed for Windows XP integration? If yes, please
nsbranch+ it?

Comment 10

[sol]

I think we really need this - a user who installs the client on an XP machine
and chooses to have us handle HTML should see the client appear as their default.

Comment 11

[Peter Trudelle]

->0.9.4, P1, cc danm cuz bill is not in.

Comment 12

[Marek Z. Jeziorek]

nsbranch+ per pdt triage
danm, could you take it?

Comment 13

[Asa Dotzler [:asa]]

0.9.4 is out the door.

Comment 14

[Asa Dotzler [:asa]]

0.9.4 is out the door.

Comment 15

[Bill Law]

Attachment: tentative patch (work in progress; handing off to Sean)

Comment 16

[Jaime Rodriguez, Jr.]

Samir - Can you take a look at this one, and let me know, if you have time to
get this resolved in the next couple of days? thanks . . .

Comment 17

[Samir Gehani]

Sean (or Dan) is better qualified to handle the vagueries of the windows
registry (especially since this involves different behavior of various windows
flavors).  I can help out under his instruction but don't honestly think I can
get to this and complete it on my own in the next few days given the other bugs
for this week.  

Comment 18

[Jaime Rodriguez, Jr.]

Dan - Can you take a look at this one? We really need the help.

Comment 19

[Dan M]

danm? dveditz? I'm going to defer to law, the bug's current owner. He knows more 
about this stuff than I. Personally, I'm currently doomed for 0.9.4, and not 
looking for any immediate new challenges.

Comment 20

[lchiang]

doron - if you want to remain the QA contact to verify this bug, go ahead and
change back to you as qa contact.  Thanks.

Comment 21

[Bill Law]

Attachment: Updated patch; has been tested on on WinXP configuration; ready for review (and further testing)

Comment 22

[Bill Law]

I think I have this under control.  We need to exercise this patch on as many
WinXP systems as possible.  I'll start pursuing that.

Also need review and super-review.  I'd like Sean to review it.

This patch also fixes another problem related to saving un-set registry keys. 
That's the simple addition of the char array initializer at the end of the patch.

Note that this is a patch for the branch revision of the file.

Comment 23

[Bill Law]

After talking to Sean some more, we decided to add code here to register the 
app as a "start menu internet application" under 
HKLM\Software\Clients\StartMenuInternet, rather than rely on the fact that 
WindowsXP seems to do it for us.

So I've added 3 RegistryEntries for that, and re-arranged the code.  Another 
patch is coming...

Comment 24

[Bill Law]

Attachment: Updated patch per comments above.

Comment 25

[Jaime Rodriguez, Jr.]

Get some QA help, and into the trunk when you can.

Comment 26

[Bill Law]

Attachment: Latest rev with suggeestions from Sean; still need to add "broadcast" when we change settings

Comment 27

[Bill Law]

Attachment: Final rev, with broadcast of WM_SETTINGCHANGE

Comment 28

[Jaime Rodriguez, Jr.]

Bill - We need this bad boy. When will it be in the trunk? How close are you to
getting your reviews? - PDT

Comment 29

[Bill Law]

Sean has OK'd it (r=); I've asked Blake to sr and he said he would, yesterday. 
I'll get after them to update the patch with those reviews.

The patch for the trunk has to be different and I haven't done that yet.

Comment 30

[Sean Su]

there's also an installer change that need to happen along with this, but it's 
not a UI change.

Essentially, the installer needs to stop registering the Windows registry keys 
that places the browser (and also mail) in the "list of available defaults apps" 
because Bill's code will be doing that.  The installer just needs to add these 
same keys to its uninstall log file at installation time so they can be properly 
removed during uninstall.  I'll work on the patch right now.

Comment 31

[Blake Ross]

My DSL was down all afternoon yesterday and was this morning. I'm at school now 
but don't think I have enough time to look over all this.  Assuming it's up when 
I get home, I'll get right on it...

Comment 32

[Bill Law]

Attachment: Additional code to suppress "default browser" dialog when user has restricted access

Comment 33

[Bill Law]

Sean discovered that when running as a "Limited" WinXP user, the user always
gets the "Do you want this to be your default browser" dialog.  We can't set the
registry keys to say we've already shown that dialog.

The additional patch adds code to detect this situation and suppress the dialog
in that case.

Comment 34

[Sean Su]

Attachment: patch to update installer do undo WinXP Start menu (ns tree)

Comment 35

[Sean Su]

Attachment: patch to update installer do undo WinXP Start menu (moz tree)

Comment 36

[Bill Law]

Comment on attachment 50913 [details] [diff] [review]
patch to update installer do undo WinXP Start menu (ns tree)

I'm trusting Sean on the details of these installer script tweaks.  But the intended outcome is what we want.

Comment 37

[Daniel Veditz [:dveditz]]

Comment on attachment 50913 [details] [diff] [review]
patch to update installer do undo WinXP Start menu (ns tree)

sr=dveditz

Comment 38

[Daniel Veditz [:dveditz]]

Comment on attachment 50914 [details] [diff] [review]
patch to update installer do undo WinXP Start menu (moz tree)

sr=dveditz

Comment 39

[Blake Ross]

Well, my internet connection just started working finally. The patch looks good,
but I guess it's too late for that. I do want to say thank you (and hug you and
kiss you) for fixing the problem that the default browser dialog always appears
on startup in XP. That was getting real old real fast...

Comment 40

[Jaime Rodriguez, Jr.]

Chaning ETA to 09.27

Comment 41

[Blake Ross]

Comment on attachment 50779 [details] [diff] [review]
Additional code to suppress "default browser" dialog when user has restricted access

sr=blake

(Nit, verifyRestrictedAccess() is sort of an odd name for its purpose)

Comment 42

[Bill Law]

Yes, I thought so, too, but that was what it was called in the sample code Sean
gave to me.  I didn't want to look a gift horse in the mouth.  But I think I'll
change it to "hasRestrictedAccess."

Comment 43

[Jaime Rodriguez, Jr.]

check it in - PDT+

Comment 44

[Sean Su]

bill said that his patches have been checked in.  I just checked mine in as 
well.  closing bug as fixed (for branch only).

Comment 45

[Grace Bush]

verified on branch build 2001100505