This start page setting is getting on my nerves.
I routinely switch between 0.9.4 and the trunk. When I do this, I get the
"welcome to mozilla" page. Every single time.
There is no way to turn this off without editing the code. Please, either give
me a pref to turn this off always, or teach the version comparison code to not
just do a plain string compare, so that I can set the pref to version 99.99.99.
> There is no way to turn this off without editing the code.
in users.js would do the trick?
Nope. Anything other than the current mstone value sends it to
It's annoying as all heck for those of us already "in the know".
sounds like a dup of bug 99899
No, it's not :-) Bradley want's to be able to turn of the start_page_override_url.
Would it fix it to get the checking code to only show the URL if the version
number had increased? And not to reset the version number in the pref if it was
a decrease? This way your version number pref would stay at the highest value
that had ever been run, and none of the lower-valued ones would show the start_page.
That WOULD help because then we could set it to 0.9.9+ and never see it till 1.0
Make it so, Mr. Markham. ;)
I know nothing about that bit of code at all :-(
Well quit making pointless entries into bugzilla and LEARN .;)
gerv: well, I could set it to my home page, and then I wouldn't notice the
difference. However, I've used this profile with 6.1 (yes, yes, I know), and so
I have an entry:
But when I start blizzard's 0.9.4 rpms, I get the mozilla start page. Something
else is going on, and so that trick won't work.
(That page resizes. Do you know how annoying that was before I discovered it
The problem with the version number is that theres no real definition of
increasing. If you ever run a netscape build, it would be set to 6.x, and then
would never show the mozilla start page. While I know that we don't support
that, I suspect that first-time mozilla people would use an existing profile. Or
do the commercial releases use the mozilla milestone value?
jag: any comment here?
Samir: I'll take this bug (but feel free to take it back if you really want it).
Set the following pref to any string in your user.js and then run the browser
twice. The second time onwards you should never see the homepage override
mechanism kick in no matter whether you use mozilla or ns builds.
Pref you want is: browser.startup.homepage_override.mstone
No, that makes the start page _always_ show!
If I do that, then we see that the pref milestone doesn't match the current one,
and display the page, but because its now in user.js, it never gets updated.
I'm pretty sure Samir meant to say prefs.js.
But that doesn't help either - it will still always show when swapping between
0.9.4/trunk. If I set the url to "foo", then foo != "rv:0.9.4", so it displays.
And then the code writes out the setting of rv:0.9.4, and we're back where we
Yep. So, here's my proposal: add another pref that allows developers to turn
this feature off, but it'll be set by default to always display the url when the
Rather than ANOTHER pref, why not just check to see if either the override URL
or mstone value is equal to a predefined value, say "none", and if so, don't
override. If != "none" (or whatever) then continue with checking if the mstone
has changed, etc... ?
"latest". I like your idea.
Glad to hear it. :) I'll take a look at the code tomorrow to see if I can make a
simple patch for it.
Ok, I guess the relevant file and position is currently
which is where the milestone check block starts. SO, maybe we have this section
(I'm including line numbers so it's easier to find when viewing the source):
905 // failed to get pref -or- saved milestone older than current milestone,
906 // write out known current milestone and show URL this time
907 if (NS_FAILED(rv) ||
910 // update milestone in "homepage override" pref
913 return PR_TRUE;
916 // don't override if saved and current are same
917 return PR_FALSE;
So I guess lines 907 and 908 hold they key.
Actually, I forgot to mention you would need to set general.useragent.misc
to the same string and I did mean user.js.
Yeah, I realized you did mean user.js after thinking about it some more. The
missing factor was indeed overriding the misc string in the same way.
So, I looked at this. We initialise http at startup, for the sole purpose of
getting the a single pref. Yuck.
Anyway, I don't want to change my browser's useragent to get rid of this.
Would people object to a HOMEPAGE_OVERRIDE_MILESTONE of 'latest' meaning that we
don't show this page? IF so, I'll code it up, and try to get it into 0.9.5.
If we are initialising HTTP at startup solely because of this feature, then it
needs a total rethink.
according to darin its loaded at startup for a couple of other reasons.
Thats no excuse for just not reading the pref directly though, but thats a
separate issue to this bug, which I want fixed for 0.9.5.
We could also concatenate all the versions we've seen into the pref and then
scan for it. That way it would do the right thing even for folks who don't know
about this magic value, although at the cost of a pretty long pref eventually.
*** Bug 122940 has been marked as a duplicate of this bug. ***
*** Bug 123810 has been marked as a duplicate of this bug. ***
Bug 99441 covers the problem where a "Welcome to Netscape 6.1!" page appears
instead of Mozilla's new-milestone page.
might be interesting:
i use server based profiles (w95b, w98se, Mozilla v 0.9.6 - Build 2002041711)
and always got the start page on a client where i had installed windows on
drive 'd:' instead of 'c:' (and the folder 'program files' that contained the
mozilla files). now mozilla is installed on all clients on the same drive and in
the same folder and the welcome-page doesnt appear any longer.
with netscape 4.x i had similar problems. the 'drive d: netscape' always forgot
the cache and the cookie settings.
why not change the homepage override ?
Build V1 -> Profile V2 -> V2 changed to V1 in the profile -> Mozilla/NS Start Page
Build V1 -> Profile V2 -> no start page override and V2 remeains in the profile
Build V2 -> Profile V1 -> Mozilla/NS start page
*** Bug 235981 has been marked as a duplicate of this bug. ***
Tweaking summary so I could have found it before filing my duplicate.
As much as I hate this behaviour myself, I don't believe that this bug's
severity is appropriate. I'd marked mine as an enhancement calling for a hidden
preference because I see what the browser does as a good thing for people who
aren't aware of how they can get involved. Only people who know enough about
the product to be able to track it down should (implicitly acknowledging that
they're already involved) should be able to turn it off. Further, even if it's
a legitimate bug (I'm not sure how it can be) it's certainly not, objectively
speaking, "major" by any stretch of the imagination that I can see...
Created attachment 142634 [details] [diff] [review]
magic value "ignore" skips the milestone homepage hijack
Oh for petesake. This isn't difficult, and it is annoying.
I'd give this patch r+, but it wouldn't mean anything. He's got an excellent
Comment on attachment 142634 [details] [diff] [review]
magic value "ignore" skips the milestone homepage hijack
Thanks, jag. Fixed in 1.7b: set your browser.startup.homepage_override.mstone
pref to "ignore" (by hand) and you get to keep your homepage.
*** Bug 357020 has been marked as a duplicate of this bug. ***