Closed
Bug 99441
Opened 23 years ago
Closed 15 years ago
Activation messes up Mozilla's startup.homepage_override_url
Categories
(SeaMonkey :: General, defect)
SeaMonkey
General
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: jag+mozilla, Assigned: jag+mozilla)
References
Details
(Keywords: helpwanted)
Attachments
(2 files)
1.96 KB,
patch
|
jag+mozilla
:
review+
jband_mozilla
:
superreview+
|
Details | Diff | Splinter Review |
2.13 KB,
patch
|
Details | Diff | Splinter Review |
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).
Assignee | ||
Comment 1•23 years ago
|
||
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).
Status: NEW → ASSIGNED
Assignee | ||
Comment 2•23 years ago
|
||
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 ;-)
Assignee | ||
Comment 3•23 years ago
|
||
Assignee | ||
Comment 4•23 years ago
|
||
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.
Attachment #49203 -
Flags: review+
Comment 5•23 years ago
|
||
CC'ing Dan who was wondering how this all.js pref got written to a user's prefs file.
Comment 6•23 years ago
|
||
r=gerv. Gerv
Comment 7•23 years ago
|
||
Comment on attachment 49203 [details] [diff] [review] Quick fix for Mozilla 0.9.4 trunk [Checkin: Comment 8] sr=jband what Syd said.
Attachment #49203 -
Flags: superreview+
Comment 8•23 years ago
|
||
a=asa. Checked in. I'm leaving this bug open until I back it out again. Gerv
Comment 9•23 years ago
|
||
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•23 years ago
|
||
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
Assignee | ||
Comment 11•23 years ago
|
||
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•23 years ago
|
||
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•23 years ago
|
||
Assignee | ||
Comment 14•23 years ago
|
||
Yes, that's definitely a good start.
Assignee | ||
Comment 15•23 years ago
|
||
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 :-)
Target Milestone: --- → mozilla0.9.5
Comment 16•23 years ago
|
||
bug 99899, bug 100369
Comment 17•23 years ago
|
||
jag: are those two bugs R.K.Aa quoted a result of this problem? Gerv
Assignee | ||
Comment 18•23 years ago
|
||
No, those two bugs seem to be a different problem (though I'm not exactly sure what yet).
Comment 19•23 years ago
|
||
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•23 years ago
|
||
grace/lisa - These bugs are starting to pop up. Have started to test different installation scenarios?
Comment 21•23 years ago
|
||
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
Assignee | ||
Comment 24•23 years ago
|
||
-> future, helpwanted
Keywords: helpwanted
Target Milestone: mozilla0.9.7 → Future
Comment 25•22 years ago
|
||
*** Bug 137924 has been marked as a duplicate of this bug. ***
Comment 26•22 years ago
|
||
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•22 years ago
|
||
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).
Blocks: advocacybugs
Keywords: mozilla1.0.1
Comment 28•22 years ago
|
||
*** Bug 138187 has been marked as a duplicate of this bug. ***
Comment 29•22 years ago
|
||
*** Bug 141865 has been marked as a duplicate of this bug. ***
Updated•20 years ago
|
Product: Browser → Seamonkey
Updated•16 years ago
|
Attachment #49203 -
Attachment description: Quick fix for Mozilla 0.9.4 trunk → Quick fix for Mozilla 0.9.4 trunk
[Checkin: Comment 8]
Comment 30•16 years ago
|
||
Jag, Can you check what is left of this bug ?
Target Milestone: Future → ---
Comment 31•15 years ago
|
||
> 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!
Status: ASSIGNED → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•