840411 - If browser.startup.homepage_override.mstone is set to ignore, about:home doesn't work

Status: RESOLVED WORKSFORME

(Firefox :: General, defect)

Description

[Mike Kaply [:mkaply]]

A common thing for enterprise users to do is to set this pref:

pref("browser.startup.homepage_override.mstone", "ignore");

This causes the update pages not to appear.

Unfortunately, it appears the code that sets the search engine for about:home depends on ignore NOT being set:

https://mxr.mozilla.org/mozilla-esr17/source/browser/components/nsBrowserContentHandler.js#579

So if you set override mstone to ignore, about:home doesn't work on the ESR.

Comment 1

[Mike Kaply [:mkaply]]

This is a major issue for the ESR.

Unfortunately the about:home rewrite didn't go in until Firefox 18.

Comment 2

[Marco Bonardo [:mak]]

I don't think there's a regression to find, about:home always used the homepage_override stuff, until the recent rewrite (bug 749477) that made it not depend on that stuff anymore.
Unless we want to backport that change, the only workaround is to also set the homepage to something else, not about:home.

Comment 3

[Mike Kaply [:mkaply]]

(In reply to Marco Bonardo [:mak] from comment #2)
> I don't think there's a regression to find, about:home always used the
> homepage_override stuff, until the recent rewrite (bug 749477) that made it
> not depend on that stuff anymore.
> Unless we want to backport that change, the only workaround is to also set
> the homepage to something else, not about:home.

That's not really a workaround.

A user can always get to about:home by typing it or resetting the homepage.

Comment 4

[Marco Bonardo [:mak]]

(In reply to Michael Kaply (mkaply) from comment #3)
> A user can always get to about:home by typing it or resetting the homepage.

The former is not an interesting case (why should the user do that, and even if he does, why should he expect that to work?). regarding the latter I thought you could block prefs from being modified...

Comment 5

[Mike Kaply [:mkaply]]

(In reply to Marco Bonardo [:mak] from comment #4)
> (In reply to Michael Kaply (mkaply) from comment #3)
> > A user can always get to about:home by typing it or resetting the homepage.
> 
> The former is not an interesting case (why should the user do that, and even
> if he does, why should he expect that to work?). regarding the latter I
> thought you could block prefs from being modified...

You're assuming that if someone wants to block the override page, they want to completely lock down the browser.

Blocking the override page is something companies do even if they don't change any other preferences.

So having that break about:home is not acceptable.

Comment 6

[Marco Bonardo [:mak]]

No, I'm saying that if we can't backport a fix to about:home THEN it would be clever to change and lock the homepage.  The only fix we can port is bug 749477, that I'm not sure respects the guidelines for approval, so there must also be an alternative solution in case.
Why is this bug now so much important, when about:home has always been broken from the initial implementation, when you lock the override? Was it working in ESR 10?

Comment 7

[Mike Kaply [:mkaply]]

Argh. It was broken on ESR10 as well.

I don't understand why folks don't test these things until the last minute.

Removing tracking esr17 since it isn't even an ESR regression.

Comment 8

[Mike Kaply [:mkaply]]

This works past esr 17.