408944 - Nightly updates clobber default browser setting for all administrator users

Status: RESOLVED WORKSFORME

(Firefox :: Shell Integration, defect)

Description

[Boris Zbarsky [:bzbarsky]]

OS: Windows XP

BUILD: Current trunk as of today

STEPS TO REPRODUCE:
1)  Create two accounts on a Windows XP system.  Give them both administrator
    access.  Call the users A and B.
2)  Install Firefox 2.0.0.latest as one of these accounts.  I don't think it
    matters which one is used here.
3)  Set this Firefox 2.0.0.latest as the default browser in all these accounts.
4)  As user A, install current Minefield.  Set it as user A's default browser.
5)  Wait one day; install the daily Minefield update as user A.
6)  Check user B's default browser.

EXPECTED RESULTS: User B's default browser is Firefox 2.0.0.latest

ACTUAL RESULTS: User B's default browser is Minefield, which starts up against the existing Firefox 2.0.0.latest profile.

ADDITIONAL INFORMATION:
I tried resetting user B's default browser to be Firefox 2.0.0.x again, and every single nightly update done by user A silently resets it back to Minefield.

Another non-administrator user C using the same machine is NOT affected the way user B is.  Another administrator user D IS affected.

For what it's worth, I discovered this when I saw my mother using Minefield.  Turns out, my brother has been using it in his account, which is fine, but she certainly shouldn't have gotten stuck with it.  Further, she's now stuck with whatever needs to be done to merge her bookmark data between places and the Firefox 2 stuff (which she's still been using, since that's the shortcut on her desktop).

So there's a pretty serious dataloss issue here for unsuspecting parents of our alpha testers!  For now I asked my brother to stop testing trunk, until this is resolved, so he won't clobber Mom's default browser.

Comment 1

[Robert Strong (they/them - no direct email)]

The root of the problem here is that Windows only allows one registry entry per application for OS Integration for browsers. Specifically, HKLM\Software\Clients\StartMenuInternet\APP.EXE

The proper way to accomplish this would be to use a different name for each binary (e.g. minefield.exe, bonecho.exe, and firefox.exe) but this would not fix the other use case where someone wants to have two versions of a nightly branch, nightly trunk, or official.

Comment 2

[Robert Strong (they/them - no direct email)]

note: when I say "the proper way to accomplish this" I am referring to our model where we want users to have side by side installations of Firefox. Typically browsers and many other apps don't allow side by side installations on Windows due to this and other issues which in our case we do our best to workaround when possible.

Comment 3

[Boris Zbarsky [:bzbarsky]]

I'm confused...  The issue is that one user's choice of default browser is impacting another user.  Since they can have different default browsers to start with, there are clearly two different places where the information is stored, right?  The problem is that the update overwrites both places, no?

Comment 4

[Robert Strong (they/them - no direct email)]

There is more to it than just that. There is the ability to add all of the registry entries for a single app basis on per user basis and this problem only appears when there are two installs of the same app. So, we can add protocol and file handlers on a per user basis which I believe solves most of the problem that you reported (see bug 353814 which was fixed on the trunk by bug 370571). We can't add registry keys on a per user basis for the StartMenuInternet which provides additional OS Integration such as the Internet entry at the top left of the start menu.

This became even more problematic with Vista since we had no choice but to set our registry keys during installation (btw: this is what MS recommends) since the application wouldn't have the ability to set these keys when the user is running with UAC turned on. We have since moved on the trunk the setting of these registry keys into a separate binary (this is the was IE has always done it) so we are now able to request elevation so we have the rights to set these keys.

I am working on making a branch patch for bug 370571 but the two installations will still fight over the StartMenuInternet registry keys and there is currently no solution for that.

Comment 5

[Boris Zbarsky [:bzbarsky]]

Fun...  I mostly see Mom hitting this when she clicks links in a Word document or something, so the start menu thing should be less of a problem in this particular case.

That said, the bugs you cite are fixed on trunk, right?  But in this case it's a trunk build clobbering the settings.  I guess what I can't understand is why, if trunk is setting its registry keys on a per-user basis, it's affecting other users at all.

Comment 6

[Robert Strong (they/them - no direct email)]

The trunk clobbers the branch because we set the keys during installation and on the branch we don't set the keys in HKCU when setting an app as the default if we have rights to set them in HKLM which is the same thing as IE does. On the trunk we set them in both HKCU and HKLM primarily because of bug 369703.

I think you will find that in step 4 of the steps to reproduce that several of the default browser settings have already been clobbered.

Comment 7

[Boris Zbarsky [:bzbarsky]]

Oh, I see.  The problem is branch not writing (or reading, for that matter?) the per-user settings if it can use the global ones.  Gotcha.  Changing the version field accordingly.

Is there anything that can be done with the trunk build in question to mitigate the problem (short of turning off the update mechanism and not installing any newer trunk versions, which is what we've done for now)?

Comment 8

[Robert Strong (they/them - no direct email)]

I haven't put any thought into a manual user end workaround and will do so next week.

Comment 9

[Daniel Veditz [:dveditz]]

I'm not sure this kind of thing is what the "dataloss" keyword was meant for. Can't really see blocking the branch release for this -- kind of an edge case and no owner stepping up to fix this.

Comment 10

[Robert Strong (they/them - no direct email)]

Daniel, this will be fixed by bug 370571 per comment #4 after the 1.8 tinderboxen have NSIS upgraded.

Comment 11

[Daniel Veditz [:dveditz]]

> this will be fixed by bug 370571 per comment #4 after the 1.8
> tinderboxen have NSIS upgraded.

Why would the 1.8 branch tinderboxen have their NSIS upgraded? Is bug 370571 supposed to be blocking 1.8, or missing an approval request?

Comment 12

[Robert Strong (they/them - no direct email)]

I'm fairly certain this bug has been fixed by bug 370571 and other bugs. If this is still reproducible please either comment in this bug or file a new one.