324093 - upgrading firefox shouldn't always result in setting homepage_override.mstone

Status: RESOLVED INVALID

(Toolkit :: Application Update, defect, P3)

Description

[Mike Beltzner [:beltzner, not reading bugmail]]

After applying the Firefox 1.5.0.1 update (from the beta channel), a user is brought to the Firefox Central page (listed in URL) when the browser restarts. This is confusing behaviour, and will make users thing that their home page has been changed.

<hand-waving>
I *think* that what's happening here is that after an update is applied, code is run that generates a URL for a "What's New" page (these were used for 1.5 alpha, beta and RCs, as I recall) and sends the browser there. I know that for release, that URL redirects to Firefox Central (by design) to give users a first-run welcome experience. I'm *guessing* that's exactly what's happening here. So the fix would be to either create a "What's New" page for 1.5.0.1, or to somehow disable this behaviour.
</hand-waving>

Comment 1

[Mike Beltzner [:beltzner, not reading bugmail]]

This totally needs to be fixed before we ship Firefox 1.5.0.1.

Comment 2

[Mike Beltzner [:beltzner, not reading bugmail]]

LXR reference:
http://lxr.mozilla.org/mozilla/source/browser/components/nsBrowserContentHandler.js#108

Comment 3

[Mike Shaver (:shaver emeritus)]

I think we should just take this mechanism out entirely, or restrict it savagely to only the new-profile (likely new-user) case.  At present, it's at least as confusing as 314119, and incurs real cost in order to derive hypothetical value.

If you are not new to Firefox, we should not tell you about Firefox.  If your upgrade went smoothly (as it likely will if you don't have extensions), you should be right back in business.  The flowers will remain standing.

Comment 4

[:Gavin Sharp [email: [e-mail]]]

Attachment: patch

Only show the "override" page for profiles without the "mstone" pref (new profiles), and update the pref if it's out of date, to ensure that no one relying on it breaks.

Comment 5

[:Gavin Sharp [email: [e-mail]]]

Checked in on the trunk.
mozilla/browser/components/nsBrowserContentHandler.js;               1.21;
mozilla/browser/components/bookmarks/src/Makefile.in;                1.17;
mozilla/browser/components/bookmarks/src/nsBookmarksFeedHandler.cpp; 1.11;

Comment 6

[Darin Fisher]

> Only show the "override" page for profiles without the "mstone" pref (new
> profiles), and update the pref if it's out of date, to ensure that no one
> relying on it breaks.

Wait a second.  Does this mean that when users upgrade from FF 1.5 to FF 2.0 that they will not see the override page?  Will we need to restore that functionality before the 2.0 release?  If so, please be sure to file a bug on that.

Comment 7

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #6)
> > Only show the "override" page for profiles without the "mstone" pref (new
> > profiles), and update the pref if it's out of date, to ensure that no one
> > relying on it breaks.
> 
> Wait a second.  Does this mean that when users upgrade from FF 1.5 to FF 2.0
> that they will not see the override page?  Will we need to restore that
> functionality before the 2.0 release?  If so, please be sure to file a bug on
> that.

Yes, it does. That was the behavior that was requested by Mike Connor after discussion on IRC. It seems like there are two use cases:
1) New profile, which is assumed to be a new Firefox user
2) New version, which is assumed to be a previous Firefox user that has upgraded.

Seems like both cases should be handled, with different behavior for each. My patch makes the redirect suitable for 1), but doesn't handle 2). Currently, the 2) situation redirects to "Firefox Central" which isn't really relevant to existing users (none of the features explained there are "new" in 1.5/1.5.0.1), so this fixes it for 1.5.0.1, as you said. Bug 314119 has some related discussion, I think it would be a suitable place to discuss whatever needs to be done for Firefox 2.

Comment 8

[Daniel Veditz [:dveditz]]

This should not have gone in without broader discussion. If it's useless why preserve it for the new-profile case? Maybe we want to rip it out, but that doesn't help 1.5.0.1 which is what this bug is about. We can talk about 1.5.0.2, but the QA cost of respinning at this point means we want a web page fix.

"central" was always a bad page for this feature, even for first-time users. The page should have had something that was very clearly one-time content, like "Thank you, you have successfully installed Firefox version X.X.X" with links to
 - more info about the product (maybe "central")
 - technical support (http://www.mozilla.org/support/)
 - a prominent button or link to continue to their normal home page
   (or if that's technically difficult--would require sending it from
   from our client to the server or generating the page in the client--a
   note mentioning that next time they'll get their home page and that they
   can use the 'house' icon this time)

So for 1.5.0.1 -- Is someone going to come up with a page, or are we going to WONTFIX it?

Comment 9

[:Gavin Sharp [email: [e-mail]]]

(In reply to comment #8)
> This should not have gone in without broader discussion. If it's useless why
> preserve it for the new-profile case? Maybe we want to rip it out, but that
> doesn't help 1.5.0.1 which is what this bug is about. We can talk about
> 1.5.0.2, but the QA cost of respinning at this point means we want a web page
> fix.

As I understand it, the existing page isn't useless for new users - it's useless for existing, upgrading users (who already know about tabs, live bookmarks, and the searchbar). This was meant to be a fix for 1.5.0.1, nothing else; Beltzner asking for blocking led me to believe that was still a possibility. I landed it on the trunk only so that it could be tested and verified beforehand, I should have made that clearer. As mentioned in my previous comment, bug 314119 has discussion about a more complete solution.

Comment 10

[Daniel Veditz [:dveditz]]

> This was meant to be a fix for 1.5.0.1, nothing else; Beltzner asking for
> blocking led me to believe that was still a possibility.

Respinning 1.5.0.1 means not shipping this week. We can consider the fix for 1.5.0.2, but for 1.5.0.1 it's either a new web page or nothing. A new page means also changing the redirect javascript at http://www.mozilla.org/products/firefox/releases/whatsnew/ or web-server sniffing to do the same.

Comment 11

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #6)
> Wait a second.  Does this mean that when users upgrade from FF 1.5 to FF 2.0
> that they will not see the override page?  Will we need to restore that
> functionality before the 2.0 release?  If so, please be sure to file a bug on
> that.

Yes. As Shaver points out in comment 5, the fact that the version number changes is not reason enough alone to force an override to the user's set homepage. If there's a significant change in a code release that deserves the user's attention, then the place to force that redirect is in the newly released code. In other words, only redirect users with existing profiles when absolutely neccessary. So, also yes, if we decide this is needed for Fx2, then we'll have to file a bug for that.

Note that this means that if we think that RC/beta users should always get that initial redirect to the "What's New in This RC?" page, then that code would be specific to that RC/beta. I can live with that, if the release team can.

(In reply to comment #8)
> This should not have gone in without broader discussion. If it's useless why
> preserve it for the new-profile case? Maybe we want to rip it out, but that

We can't make any guaranteed assumptions about the new-user-ness of a new-profile case, so we should be defaulting to the path which results in the user getting pointed to our "welcome, new users!" content (which, for the time being, is Firefox Central ... as Gavin mentions, bug 314119 aims to fix that). We *can* make a guaranteed assumption about new-user-ness of an existing-profile case.

Our statement here is not that the current mechanism for new users is perfect. The statement is that the current mechanism for existing users upgrading to 1.5.0.1 is inappropriate, and should be removed since there's really no significant UI/functional delta that a user needs to be made aware of.

> doesn't help 1.5.0.1 which is what this bug is about. We can talk about
> 1.5.0.2, but the QA cost of respinning at this point means we want a web page
> fix.

The bug was filed as soon as I realized that this happened to people who were updated to 1.5.0.1 and marked blocking immediately thereafter. I'm not exactly sure how I could have gotten it more attention, especially since I hadn't seen any dates on the 1.5.0.1 release cycle so I was unaware of any pending deadlines.

If it can't make 1.8.0.1, then minus that flag. I can take it. :)

> "central" was always a bad page for this feature, even for first-time users.
> The page should have had something that was very clearly one-time content, 

Agreed, but that's not what this is about, that's what bug 314119 is about. (Also, for the record, creating new content for that page and localizing it doesn't turn out to be any easier, time-wise, than respinning a build. Don't make the mistake of assuming that server-side fixes are always easier than respinning builds.)

> "Thank you, you have successfully installed Firefox version X.X.X" with links
> to
>  - more info about the product (maybe "central")
>  - technical support (http://www.mozilla.org/support/)
>  - a prominent button or link to continue to their normal home page
>    (or if that's technically difficult--would require sending it from
>    from our client to the server or generating the page in the client--a
>    note mentioning that next time they'll get their home page and that they
>    can use the 'house' icon this time)

I think this is all ridiculously heavy for the 1.5.0.1 upgrade, which was the impetus for this bug. It has a zero-effect on the user's experience, and using the default settings, they'll hopefully barely even notice that the update was installed in the first place (since it should download and install automatically and be ready on their next startup).

> So for 1.5.0.1 -- Is someone going to come up with a page, or are we going to
> WONTFIX it? 

I've changed the summary of this bug to not be specific to 1.5.0.1/1.8.0.1, and filed bug 324499 to track the band-aid solution we'll have to put together for 1.5.0.1.

Comment 12

[Daniel Veditz [:dveditz]]

Thanks for the explanation Mike, and with that minusing for 1.5.0.1

> (Also, for the record, creating new content for that page and localizing it
> doesn't turn out to be any easier, time-wise, than respinning a build.

fwiw this particular page is not localized. The override URL points at a whatnew page that redirects to central for en-US but sends everyone else to the localized google-firefox start page:
view-source:http://www.mozilla.com/firefox/releases/whatsnew/

The standard homepage seems even worse than throwing up central -- people must really think we've hijacked their homepage! That's just horrible.

> Don't make the mistake of assuming that server-side fixes are always
> easier than respinning builds.)

Not easier, but the schedule is slightly different. Page changes can be made after the final bits are being verified.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

Accuse me of being snyde at your leisure, but I'd like to point out that we respun and didn't take this patch in the interim. We need to figure out a better way of doing things so that when there are ultra-low-risk-high-benefit patches available, they get picked up during respins of a release.

Comment 14

[:Gavin Sharp [email: [e-mail]]]

I don't think there is anything left to do in this bug for 1.5.0.2. The redirect that was setup as an alternative is probably doing a good enough job, and changing the user expectation of "new build confirmation" messages doesn't seem worth it. I think this bug should be closed and attention turned to bug 314119 for a cleaner Firefox 2 solution.

Comment 15

[Mike Beltzner [:beltzner, not reading bugmail]]

Closing this bug down isn't the right thing to do, but retargetting it for Firefox 2 seems appropriate as we discussed on IRC. Clearing blocking1.8.0.2 status.

Note to self: open a bug that blocks 1.8.0.2 to get Steven to update the redirect page for the 1.5.0.2 release ...

Comment 16

[Mike Connor [:mconnor]]

-> beltzner for product/design thinking, to be assigned once we work that out.

Comment 17

[Mike Beltzner [:beltzner, not reading bugmail]]

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

Comment 18

[Gudmund Areskoug]

(In reply to comment #17)
> *** Bug 336562 has been marked as a duplicate of this bug. ***
> 

...continuing the thread from 336562, sorry if this isn't how it's done.

Mike Beltzner wrote:
"The basic text is what appears in the box, which is the "You've got the latest
updates for security and stability" message. This is essentially a hack right
now, and only there because the code requires us to override the user's
homepage when we change the application version string. In the ideal, we
wouldn't show them anything at all (except maybe some sort of "you've been
upgraded, huzzah!" message that's non-modal), since the types of things we fix
in stability and security upgrades that the average user can't decode. Note
that: release Notes are always available in the help."

Yes, release notes exist in help, as already noted. IMHO keeping users in the dark belongs to, well, the dark side. 

If FF were to update without even telling the user (or did I get you wrong?), the user wouldn't even know he/she should look into the Help > Release Notes, so I think it would definitely be better to keep the user informed, *at least* with a link to the release notes. 

Whether that should happen via a one-time splash screen or a temporary homepage override on first startup is a purely technical matter. Only *please* don't treat users as incurable ignorants and keep them in the dark, there's enough of that out there already.

Comment 19

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #18)
> If FF were to update without even telling the user (or did I get you wrong?),
> the user wouldn't even know he/she should look into the Help > Release Notes,
> so I think it would definitely be better to keep the user informed, *at least*
> with a link to the release notes. 

There are two things here: first, whether or not there should be any indication that your software was updated; second, what that indication should be.

I think we can agree that some indication is neccessary, if for no other reason than to verify success. Where we seem to disagree is in the fidelity of that indication: minor updates are always just security and stability updates, and the release notes never really say much more than that themselves. I'd think that on a security and stability update, if anything, all we'd want is a browsermessage saying "Firefox was updated with the latest security and stability updates [Read more ...] [x]" 

This bug is stating is that the current indication -- hijacking the user's start page -- is overkill. If we think an update has a change that is significant enough to demand the user's attention, we should programmatically draw their attention in the content of that update, not automatically assume every update will require such a step.

> Whether that should happen via a one-time splash screen or a temporary 
> homepage override on first startup is a purely technical matter. Only *please* 

Agreed, and this bug is about removing the infrastructure that *requires* it to redirect the user's start page.

Maybe I was hasty in duping that previous bug. Feel free to re-open if you're willing to change the summary so that it doesn't imply that the notification mechanism MUST be a homepage-hijack. :) 

Comment 20

[Mike Connor [:mconnor]]

pushing out non-critical-path bugs to b2

Comment 21

[Mike Schroepfer]

-> beltnzer to decide what to do

Comment 22

[Mike Beltzner [:beltzner, not reading bugmail]]

I still think the right thing to do here is not to do a default homepage-hijack for every dot-dot release; ideally we should be able to package the release with a one-time redirect if it's felt to be necessary.

It would be nice to get the infobar showing the message, if we can. I've little idea of how hard that would be, or the risk involved at this stage.

Comment 23

[Mike Beltzner [:beltzner, not reading bugmail]]

Connor and I talked, and I realized that the infobar approach that I advocated in comment 19 makes far less sense in the world of session restore :(

The goals here are:
 - give the user a confirmation that the update applied cleanly, and an option to find out more about the update
 - only show this confirmation after the update
 - minimize impact on browsing

Connor suggested that we open a new tab to the "successful update" page much like bug 314119 is doing to handle the first launch page. I further suggest:

 - the updater sets a boolean app.update.notifySuccess variable to true
 - when firefox starts, if that variable = true, we open a new tab with focus (thus appending to session store of the user's homepage set) and point it to a URL constructed from some base + appversion + locale then reset app.update.notifySuccess to false

The web page for the successful update should include (this will be a follow-on bug):

 - Primary message of "update successfully completed"
 - secondary message of why, and link to release notes / more details
 - a prominent button that calls window.close() and says "Back to browsing"

Comment 24

[Daniel Veditz [:dveditz]]

In the interim it would be a practical immediate improvement (i.e. for 1.5.0.5) if the current page (http://www.mozilla.com/firefox/updated) were to be changed to make the "Go to Firefox Start page" link go to "javascript:window.home();". That would take people to their potentially customized home page rather than the hardcoded Google-hosted page (you could put the current hardcoded link in a <noscript> for those who turn off javascript).

Comment 25

[Daniel Veditz [:dveditz]]

Never mind, that's bug 343890

Comment 26

[Mike Beltzner [:beltzner, not reading bugmail]]

(In reply to comment #23)
>  - when firefox starts, if that variable = true, we open a new tab with focus
> (thus appending to session store of the user's homepage set) and point it to a
> URL constructed from some base + appversion + locale then reset
> app.update.notifySuccess to false

The url should be of the format:

http://www.mozilla.com/{locale}/firefox/{version}/updated

Comment 27

[Mike Connor [:mconnor]]

Not going to block on this, now that bug 314119 is in place.

Comment 28

[:Gavin Sharp [email: [e-mail]]]

Given bug 314119, I think this is now INVALID.