99441 - Activation messes up Mozilla's startup.homepage_override_url

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[jag (Peter Annema)]

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).

Comment 1

[jag (Peter Annema)]

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).

Comment 2

[jag (Peter Annema)]

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 3

[jag (Peter Annema)]

Attachment: Quick fix for Mozilla 0.9.4 trunk [Checkin: Comment 8]

Comment 4

[jag (Peter Annema)]

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.

Comment 5

[Samir Gehani]

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

Comment 6

[Gervase Markham [:gerv]]

r=gerv.

Gerv

Comment 7

[John Bandhauer]

Comment on attachment 49203 [details] [diff] [review]
Quick fix for Mozilla 0.9.4 trunk
[Checkin: Comment 8]

sr=jband
what Syd said.

Comment 8

[Gervase Markham [:gerv]]

a=asa.

Checked in. I'm leaving this bug open until I back it out again.

Gerv

Comment 9

[Daniel Veditz [:dveditz]]

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?

Comment 10

[Gervase Markham [:gerv]]

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

Comment 11

[jag (Peter Annema)]

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).

Comment 12

[Gervase Markham [:gerv]]

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

Comment 13

[Gervase Markham [:gerv]]

Attachment: Patch v.1 - tidying up

Comment 14

[jag (Peter Annema)]

Yes, that's definitely a good start.

Comment 15

[jag (Peter Annema)]

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 :-)

Comment 16

[R.K.Aa.]

bug 99899, bug 100369

Comment 17

[Gervase Markham [:gerv]]

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

Gerv

Comment 18

[jag (Peter Annema)]

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

Comment 19

[Gervase Markham [:gerv]]

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

Comment 20

[Jaime Rodriguez, Jr.]

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

Comment 21

[Grace Bush]

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

Comment 22

[jag (Peter Annema)]

-> 0.9.6

Comment 23

[jag (Peter Annema)]

-> 0.9.7 (deja vu?)

Comment 24

[jag (Peter Annema)]

-> future, helpwanted

Comment 25

[Jesse Ruderman]

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

Comment 26

[Jesse Ruderman]

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.

Comment 27

[Adam Hauner]

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).

Comment 28

[Matthias Versen [:Matti]]

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

Comment 29

[Daniel Veditz [:dveditz]]

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

Comment 30

[Serge Gautherie (:sgautherie)]

Jag,

Can you check what is left of this bug ?

Comment 31

[Philip Chee]

> 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!