NS' Activation fetches the "first page to display after install/upgrade" URL from the web and stores this in the user's preference file so it will get read in later when the browser startup mechanism tries to find out which page to display. By storing it in the user's prefs.js, it will override the version defined[0] in all.js. This is bad because it means that if a user uses a profile under NS, then moves to Mozilla milestone 0.9.4 he will see the NS "Welcome to 6.x" page instead of a Mozilla "So you want to contribute ..." page. This is because Mozilla expects to find the url defined in its all.js, not the overridden one in prefs.js. Actually, for Mozilla 0.9.4 one can read "any browser product based off of Mozilla 0.9.4 that wishes to use this "welcome page" mechanism. This all currently works for Netscape, since for each new release Activation will overwrite the "preference" with the new/correct URL. However, if in the future they want to have a build without Activation, they too will run into a stale "Welcome to 6.1" URL instead of the newer one defined in their all.js. Now, who is really affected by this? People who have an existing profile (under a milestone before 0.9.4), have used it under NS 6.1 and then want to switch to Mozilla 0.9.4, and people who started with NS 6.1 and want to try out Mozilla 0.9.4, or anyone switching from a 0.9.4 based browser product switching to 0.9.4 (because of the new code in 0.9.4 that shows the welcome page on existing profiles based on the milestone part of the UA string). In short, anyone who has used their profile under NS 6.1 and then uses 0.9.4 for the first time will see the NS welcome page. The quick fix (for Mozilla 0.9.4) would be to rename the pref key (by appending e.g. a "1"), thus avoiding the bogus NS 6.1 one, build, test, release 0.9.4 and then change it back so NS can work on the branch without having to change any of their code. This fix has the advantage that it's small (affects 2 files: config.js, which gets merged into all.js, and nsBrowserInstance.cpp, -2/+2), works in any combination of profile sharing, and when a better fix is found/applied, there won't be any garbage left in the user's prefs file since it's localized to the Mozilla binary. A better (since it's not Mozilla that's broken, but Activation), but more involved fix is for Activation to remove the pref when the page has displayed, by e.g. hooking up a nsWebProgressListener or some such which listens for document load start or end. This would leave the user's profile clean so that if they switch to a new Mozilla build they won't run into this problem. Users who used 6.1 won't benefit from this fix though, only users of any Netscape build(s) that will incorporate the above fix. Ideally we would do both, make a switch to a new key (perhaps better chosen than just adding a "1" to it) and fix future Netscape releases not to write the url to the user's prefs file. Or some other option, like force Mozilla to always read the default pref (from all.js) and force Activation to write to all.js (though I personally not like this since it would require writing to a potentially shared file, which may not be owned by the current user on unix systems).

Sorry, that's not quite correct. For the "quick fix", the appropriate en-US region.properties file would also need to be fixed, so -3/+3. This ties back to the "[0]" I had in my previous comment. I realize this means that any localisations done for 0.9.4 will need to update their navigator-region region.properties file. [0] (From previous comment): I say "defined" but it's really a reference to a localized version that can be found in the region.properties file referenced. See: http://lxr.mozilla.org/seamonkey/source/modules/libpref/src/init/config.js#26 "Quick fix" patch coming up (just in case).

Or config.js isn't merged with all.js. Same difference, just read config.js where I wrote all.js below, and skip the bit about merging ;-)

Comment on attachment 49203 [details] [diff] [review] Quick fix for Mozilla 0.9.4 trunk [Checkin: Comment 8] r=syd, provided this is only used for the Mozilla 0.9.4 release and removed from the 0.9.4 branch afterwards.

CC'ing Dan who was wondering how this all.js pref got written to a user's prefs file.

r=gerv. Gerv

Comment on attachment 49203 [details] [diff] [review] Quick fix for Mozilla 0.9.4 trunk [Checkin: Comment 8] sr=jband what Syd said.

a=asa. Checked in. I'm leaving this bug open until I back it out again. Gerv

The other prefs dealing with the homepage_override are all "browser.startup.homepage_override...", while this one is plain "startup.homepage_override..." When we change this "back" could we change it to match its related prefs?

I saw that as well; sounds like a good idea to me. Would there be any backwards-compatibility repercussions? My instinct is no, but I am not familiar with this code. Gerv

There wouldn't be any backward compatibility issues. This "pref" is completely contained within the binary (except for NS' Activation exposing it to the profile).

OK, the following patch fixes the issues raised. This would go on the trunk. On the branch, we just need to back out my checkins. My tree is kind of messed up for these files; can someone else do that? I know I said I would, and I am happy to - it just strikes me it might take me half an hour and someone else with a branch tree handy about 30 seconds. jag? Gerv

Yes, that's definitely a good start.

Filed a new bug in bugscape on Activation (should've done that before): http://bugscape/show_bug.cgi?id=9500 Also, we can force Mozilla to read the pref in config.js if NS' Activation can't find a way to do this more cleanly. Yes, this will break them. (And yes, I'll probably end up having to fix it if Mozilla takes this measure ;-) ). Another thing Mozilla could do (though I think it's ugly and unclean) is to just remove the homepage_override_url key from prefs.js after first use. There's no need for Mozilla itself to do this, but it's definitely a way to "get the job done". I'm very much open to other suggestions :-)

bug 99899, bug 100369

jag: are those two bugs R.K.Aa quoted a result of this problem? Gerv

No, those two bugs seem to be a different problem (though I'm not exactly sure what yet).

syd, jband: I plan to back this out at some point when the branch is open unless either of you have a problem with that. Gerv

grace/lisa - These bugs are starting to pop up. Have started to test different installation scenarios?

K'Trina and I are testing various installation scenarios. Clean installations (as we test Activation also), upgrade installations- are there some that you can think of that we can add to our list? I'm not sure this is an install problem- rather one of moving from N6.2 builds to Mozilla builds and back

-> 0.9.6

-> 0.9.7 (deja vu?)

-> future, helpwanted

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

If this is still happening with current Mozilla builds (it seems to be based on the dup), Mozilla should change the pref name due to Netscape 6.1's misuse of the pref. I ran into this bug for months, and thought that Mozilla had hard-coded the URL for the "Welcome to Netscape 6.1" page, which didn't help my perception of the Mozilla project. I only found out the solution (remove the url from prefs.js) because I hang out on irc often.

Nominating for M1.0.1 - this bug will be first, what some users will see after running new browser. Pretty bad bug, if browser has problem with own identity (from user's view).

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

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

Jag, Can you check what is left of this bug ?

> Checked in. I'm leaving this bug open until I back it out again. This was backed out by Gerv on 2001-09-13 10:40 and M1.0 is long gone. Marking as FIXED since: (A) Netscape is DOA and (b) Activation? we doan have no steenkeen activation!