Last Comment Bug 102313 - milestone home page override is very annoying - browser.startup_homepage_overide
: milestone home page override is very annoying - browser.startup_homepage_overide
Status: RESOLVED FIXED
:
Product: SeaMonkey
Classification: Client Software
Component: Installer (show other bugs)
: Trunk
: All All
-- enhancement (vote)
: mozilla1.7beta
Assigned To: Dan M
: benc
:
Mentors:
: 122940 123810 235981 357020 (view as bug list)
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2001-09-28 19:49 PDT by Bradley Baetz (:bbaetz)
Modified: 2012-01-26 18:31 PST (History)
8 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
magic value "ignore" skips the milestone homepage hijack (2.35 KB, patch)
2004-02-29 13:32 PST, Dan M
jag-mozilla: review+
jag-mozilla: superreview+
Details | Diff | Splinter Review

Description User image Bradley Baetz (:bbaetz) 2001-09-28 19:49:52 PDT
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.
Comment 1 User image Gervase Markham [:gerv] 2001-09-28 21:39:42 PDT
> There is no way to turn this off without editing the code.

Surely putting:
user_pref("startup.homepage_override_url", "about:blank");
in users.js would do the trick?

Gerv
Comment 2 User image Grey Hodge (jX) 2001-09-28 22:01:23 PDT
Nope. Anything other than the current mstone value sends it to
mozilla.org/start.html

It's annoying as all heck for those of us already "in the know".
Comment 3 User image R.K.Aa. 2001-09-28 22:26:45 PDT
sounds like a dup of bug 99899
Comment 4 User image Gervase Markham [:gerv] 2001-09-28 22:48:06 PDT
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.

Gerv
Comment 5 User image Grey Hodge (jX) 2001-09-28 23:27:01 PDT
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. ;)
Comment 6 User image Gervase Markham [:gerv] 2001-09-28 23:31:47 PDT
I know nothing about that bit of code at all :-(

Gerv
Comment 7 User image Grey Hodge (jX) 2001-09-28 23:38:43 PDT
Well quit making pointless entries into bugzilla and LEARN .;)
Comment 8 User image Bradley Baetz (:bbaetz) 2001-09-29 07:09:08 PDT
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:
user_pref("startup.homepage_override_url","http://home.netscape.com/bookmark/6_1/startuppage.html");
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
last night?)

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?
Comment 9 User image Gervase Markham [:gerv] 2001-09-30 16:28:57 PDT
jag: any comment here?

Gerv
Comment 10 User image jag (Peter Annema) 2001-09-30 18:00:27 PDT
Samir: I'll take this bug (but feel free to take it back if you really want it).
Comment 11 User image Samir Gehani 2001-10-04 18:10:40 PDT
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

Comment 12 User image Bradley Baetz (:bbaetz) 2001-10-04 18:51:00 PDT
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.
Comment 13 User image jag (Peter Annema) 2001-10-04 21:46:00 PDT
I'm pretty sure Samir meant to say prefs.js.
Comment 14 User image Bradley Baetz (:bbaetz) 2001-10-04 22:02:24 PDT
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
started.
Comment 15 User image jag (Peter Annema) 2001-10-04 22:47:13 PDT
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
mstone changes.
Comment 16 User image Grey Hodge (jX) 2001-10-04 22:56:41 PDT
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... ?
Comment 17 User image jag (Peter Annema) 2001-10-04 23:30:23 PDT
"latest". I like your idea.
Comment 18 User image Grey Hodge (jX) 2001-10-05 00:55:57 PDT
Glad to hear it. :) I'll take a look at the code tomorrow to see if I can make a 
simple patch for it.
Comment 19 User image Grey Hodge (jX) 2001-10-05 10:52:40 PDT
Ok, I guess the relevant file and position is currently
http://lxr.mozilla.org/seamonkey/source/xpfe/browser/src/nsBrowserInstance.cpp#891
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) || 
908      !(currMilestone.Equals(savedMilestone)))
909  {
910    // update milestone in "homepage override" pref
911    aPrefService->SetCharPref(PREF_HOMEPAGE_OVERRIDE_MSTONE, 
912                              currMilestone.get());
913    return PR_TRUE;
914  }
915
916  // don't override if saved and current are same
917  return PR_FALSE;


So I guess lines 907 and 908 hold they key.
Comment 20 User image Samir Gehani 2001-10-05 12:39:29 PDT
Actually, I forgot to mention you would need to set general.useragent.misc
 to the same string and I did mean user.js.
Comment 21 User image jag (Peter Annema) 2001-10-05 13:30:49 PDT
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.
Comment 22 User image Bradley Baetz (:bbaetz) 2001-10-05 14:43:00 PDT
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.
Comment 23 User image Gervase Markham [:gerv] 2001-10-05 16:39:14 PDT
If we are initialising HTTP at startup solely because of this feature, then it
needs a total rethink.

Gerv
Comment 24 User image Bradley Baetz (:bbaetz) 2001-10-05 17:53:54 PDT
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.
Comment 25 User image Daniel Veditz [:dveditz] 2001-10-05 19:40:31 PDT
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.
Comment 26 User image jag (Peter Annema) 2002-01-15 14:14:38 PST
-> Future
Comment 27 User image Matthias Versen [:Matti] 2002-02-03 05:47:13 PST
*** Bug 122940 has been marked as a duplicate of this bug. ***
Comment 28 User image Matthias Versen [:Matti] 2002-02-07 10:47:18 PST
*** Bug 123810 has been marked as a duplicate of this bug. ***
Comment 29 User image Jesse Ruderman 2002-04-17 00:50:26 PDT
Bug 99441 covers the problem where a "Welcome to Netscape 6.1!" page appears
instead of Mozilla's new-milestone page.
Comment 30 User image Manfred Lebek 2002-04-28 04:25:55 PDT
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.
Comment 31 User image Matthias Versen [:Matti] 2002-04-28 07:44:08 PDT
why not change the homepage override ?

currently :
Build V1 -> Profile V2 -> V2 changed to V1 in the profile -> Mozilla/NS Start Page

should be:
Build V1 -> Profile V2 -> no start page override and V2 remeains in the profile
Build V2 -> Profile V1 -> Mozilla/NS start page 
Comment 32 User image Matthias Versen [:Matti] 2004-02-29 05:45:05 PST
*** Bug 235981 has been marked as a duplicate of this bug. ***
Comment 33 User image Jason Bassford 2004-02-29 06:00:41 PST
OS->All.

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

Comment 34 User image Dan M 2004-02-29 13:32:57 PST
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.
Comment 35 User image Grey Hodge (jX) 2004-02-29 13:48:29 PST
I'd give this patch r+, but it wouldn't mean anything. He's got an excellent
point, however.
Comment 36 User image jag (Peter Annema) 2004-02-29 14:09:19 PST
Comment on attachment 142634 [details] [diff] [review]
magic value "ignore" skips the milestone homepage hijack

r+sr=jag
Comment 37 User image Dan M 2004-02-29 19:18:02 PST
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.
Comment 38 User image Serge Gautherie (:sgautherie) 2008-04-28 04:38:43 PDT
*** Bug 357020 has been marked as a duplicate of this bug. ***

Note You need to log in before you can comment on or make changes to this bug.