685727 - Remove What's New page from the Firefox Update Experience.

Status: VERIFIED FIXED

(Firefox :: General, defect, P3)

Description

[Laura Mesa [:lmesa] [:lvmesa]]

Because of all the recent upgrade concerns from our users and the recent chem spills, we'd like to remove the WN page from the update process for users on 4+ moving up to 7. 

Instead, we would like for them to just see their normal start page.  

This will only last until Fx 8 and we'll make decisions going forward from release to release.

Comment 1

[Nick Thomas [:nthomas] (UTC+12)]

We can use this bug to the changes to the patcher configs, once bug 459972 and bug 682805 are fixed. Those are targeted as Fx8 though.

Comment 2

[Laura Mesa [:lmesa] [:lvmesa]]

To be clear, this is just for the Fx 7 release cycle. We want to have this again with Fx 8.

Comment 3

[Nick Thomas [:nthomas] (UTC+12)]

Unfortunately, I don't think we can do that until those bugs are resolved.

Comment 4

[Laura Mesa [:lmesa] [:lvmesa]]

(In reply to Nick Thomas [:nthomas] from comment #3)
> Unfortunately, I don't think we can do that until those bugs are resolved.

So, what does that mean? We need to show the WN page regardless?

Comment 5

[Nick Thomas [:nthomas] (UTC+12)]

Firefox opens the What's New tab by default, whenever the app version has changed since the last launch. There is a way to suppress that if the right pixie dust is sprinkled into the update offer, but we need bug 459972 to do that.

Comment 6

[Laura Mesa [:lmesa] [:lvmesa]]

(In reply to Nick Thomas [:nthomas] from comment #5)
> Firefox opens the What's New tab by default, whenever the app version has
> changed since the last launch. There is a way to suppress that if the right
> pixie dust is sprinkled into the update offer, but we need bug 459972 to do
> that.

Oh, ok. So, there's no way to do this for Fx 7 then without that bug?

Comment 7

[Robert Strong (they/them - no direct email)]

It could be done in Firefox itself. ccing Gavin

Comment 8

[LegNeato]

If you look at bug bug 648330 and bug 648368, you'll see if in the branding we just give a blank URL it won't open the tab (which is what we do on Aurora).

So I think all we'd need is a patch to the official branding clearing out that URL.

Comment 9

[LegNeato]

Attachment: Update official branding to remove a url so no tab is opened after an update

Comment 10

[LegNeato]

Attachment: Update official branding to remove a url so no tab is opened after an update, now with less typos!

Comment 11

[LegNeato]

s/less/fewer/...I'm not a savage!

Comment 12

[LegNeato]

I landed it everywhere. The official branding isn't used on other branches but having the change everywhere will make sure that we don't have to transplant it after every merge:

http://hg.mozilla.org/mozilla-central/rev/59e530a7f0dd
http://hg.mozilla.org/releases/mozilla-aurora/rev/45016b4cbc88
http://hg.mozilla.org/releases/mozilla-beta/rev/364390e63960

Comment 13

[Bill Gianopoulos [:WG9s]]

I am not sure this fix accomplishes what was requested.

What was requested was to NOT show the what's new page if a user is updating from version 4 or above to version 7.

As far as I can tell this patch will also result in no what's new page on a update from 3.6.x to 7.0.  I am not sure that is desirable.

Comment 14

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

(In reply to Bill Gianopoulos from comment #13)
> As far as I can tell this patch will also result in no what's new page on a
> update from 3.6.x to 7.0.  I am not sure that is desirable.

The existing page isn't any more useful for 3.6.x users than it is for 4.0 users, AFAIK. I don't see any reason for behavior to change depending on updated-from version, and that would be quite annoying to implement. The patch fixed the bug as summarized.

Comment 15

[Bill Gianopoulos [:WG9s]]

Just wanted to make sure everyone understood that this would be the case.

Comment 16

[Laura Mesa [:lmesa] [:lvmesa]]

Thanks Bill--appreciate the heads up. Gavin, its really important that 3.6 users see the FR page when they upgrade/ Should I file a new bug for that? And can we make sure the patch we just did here allows that to happen?

Comment 17

[Laura Mesa [:lmesa] [:lvmesa]]

here's the bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=685940

Comment 18

[LegNeato]

The patch here doesn't allow this to happen AFAICT. We'd need a new bug if this new behavior would be shipped with, otherwise we should back out the patch and reopen the bug for the remaining work.

To support desired behavior we probably have to change browser/components/nsBrowserGlue.js to include a different callback @ line 691 if the type of the update == "major" (note that the snippet stuff in bug 459972 will make that behavior obsolete as we can control it in the AUS XML).

Comment 19

[Laura Mesa [:lmesa] [:lvmesa]]

(In reply to Christian Legnitto [:LegNeato] from comment #18)
> The patch here doesn't allow this to happen AFAICT. We'd need a new bug if
> this new behavior would be shipped with, otherwise we should back out the
> patch and reopen the bug for the remaining work.

Can I file a new bug in this component? Or is there a better place for it to be?
>

Comment 20

[LegNeato]

Well, first you need to decide if the current situation (no opened tab ever after an update) is more desirable than the previous situation (open tab after every update). If not, we should back out the patch to make sure we don't accidentally ship with less desired behavior.

Comment 21

[Laura Mesa [:lmesa] [:lvmesa]]

(In reply to Christian Legnitto [:LegNeato] from comment #20)
> Well, first you need to decide if the current situation (no opened tab ever
> after an update) is more desirable than the previous situation (open tab
> after every update). If not, we should back out the patch to make sure we
> don't accidentally ship with less desired behavior.

So, we don't want this to change forever. We just want this for the 7 release for now.  I don't want to change how we do this in the long term. The more desired behavior is an open tab every update, but we want to be able to turn that off when needed (fx 7).

Comment 22

[Matt Brubeck (:mbrubeck)]

(In reply to Laura Mesa [:lmesa] from comment #2)
> To be clear, this is just for the Fx 7 release cycle. We want to have this
> again with Fx 8.

(In reply to Laura Mesa [:lmesa] from comment #21)
> So, we don't want this to change forever. We just want this for the 7
> release for now.  I don't want to change how we do this in the long term.
> The more desired behavior is an open tab every update, but we want to be
> able to turn that off when needed (fx 7).

In that case, it seems like this patch should not have landed in mozilla-aurora (Fx8) or mozilla-central (Fx9) and should be backed out there.

Comment 23

[Nick Thomas [:nthomas] (UTC+12)]

(In reply to Laura Mesa [:lmesa] from comment #21)
> So, we don't want this to change forever. We just want this for the 7
> release for now.  I don't want to change how we do this in the long term.
> The more desired behavior is an open tab every update, but we want to be
> able to turn that off when needed (fx 7).

My understanding was that we were going to use bug 459972 to disable whatsnew going forward (by setting actions=silent in the update.xml), but perhaps there is more to it than that.

AIUI we didn't land the support for actions on the 3.6 branch, so
* blocking whatsnew in updates from 3.6 (or older) requires the sort of change as attachment 559363 [details] [diff] [review], but sounds like we don't want to do that
* blocking whatsnew in updates from 4.0 (or later) can also be done in the update offer
 * either by waiting for bug 459972
 * making a hack on the update server like http://diff.pastebin.mozilla.org/1327406

Comment 24

[Laura Mesa [:lmesa] [:lvmesa]]

(In reply to Nick Thomas [:nthomas] from comment #23)
> (In reply to Laura Mesa [:lmesa] from comment #21)
> > So, we don't want this to change forever. We just want this for the 7
> > release for now.  I don't want to change how we do this in the long term.
> > The more desired behavior is an open tab every update, but we want to be
> > able to turn that off when needed (fx 7).
> 
> My understanding was that we were going to use bug 459972 to disable
> whatsnew going forward (by setting actions=silent in the update.xml), but
> perhaps there is more to it than that.
> 
> AIUI we didn't land the support for actions on the 3.6 branch, so
> * blocking whatsnew in updates from 3.6 (or older) requires the sort of
> change as attachment 559363 [details] [diff] [review], but sounds like we
> don't want to do that
> * blocking whatsnew in updates from 4.0 (or later) can also be done in the
> update offer
>  * either by waiting for bug 459972
>  * making a hack on the update server like
> http://diff.pastebin.mozilla.org/1327406

Thanks Nick.  In comment 0 and 2 I was trying to be clear that we dont want to make this permanent, but we do want this functionality in case we find ourselves in a similar situation where we do want to turn this off for a coming release. We're trying to make those decisions on a case by case basis as we wait for silent updates.

Comment 25

[Robert Strong (they/them - no direct email)]

(In reply to Laura Mesa [:lmesa] from comment #24)
> (In reply to Nick Thomas [:nthomas] from comment #23)
> > (In reply to Laura Mesa [:lmesa] from comment #21)
> > > So, we don't want this to change forever. We just want this for the 7
> > > release for now.  I don't want to change how we do this in the long term.
> > > The more desired behavior is an open tab every update, but we want to be
> > > able to turn that off when needed (fx 7).
> > 
> > My understanding was that we were going to use bug 459972 to disable
> > whatsnew going forward (by setting actions=silent in the update.xml), but
> > perhaps there is more to it than that.
> > 
> > AIUI we didn't land the support for actions on the 3.6 branch, so
> > * blocking whatsnew in updates from 3.6 (or older) requires the sort of
> > change as attachment 559363 [details] [diff] [review], but sounds like we
> > don't want to do that
> > * blocking whatsnew in updates from 4.0 (or later) can also be done in the
> > update offer
> >  * either by waiting for bug 459972
> >  * making a hack on the update server like
> > http://diff.pastebin.mozilla.org/1327406
> 
> Thanks Nick.  In comment 0 and 2 I was trying to be clear that we dont want
> to make this permanent, but we do want this functionality in case we find
> ourselves in a similar situation where we do want to turn this off for a
> coming release. We're trying to make those decisions on a case by case basis
> as we wait for silent updates.
Please note that silent updates won't prevent this page from opening. Silent updates will apply an update silently when all of the preconditions are met (e.g. user hasn't changed the preferences to automatically download, user has either turned off to warn abut incompatible extensions or all extensions are compatible, etc.). The opening of a tab after an update is applied can be controlled by the update offering using Firefox specific attributes from bug 459972 and Firefox specific code... silent updates does not prevent the page from being displayed.

Comment 26

[LegNeato]

I really think it is just easiest / best to do what's in comment 18

Comment 27

[u279076]

QA will need to track this bug.

Comment 28

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

This is FIXED - addressing the followup issues in bug 685958.

Comment 29

[Nick Thomas [:nthomas] (UTC+12)]

FTR, this was backed out at bug 689679 comment #6, prior to 8.0b4.

Comment 30

[Mihaela Velimiroviciu (:mihaelav)]

Tis is fixed with the "Silent Update - whatsnew" feature (https://wiki.mozilla.org/Silent_Update_whatsnew), which landed in Firefox 8: suppress what's new page for updates to other milestone.
What's new page is no longer displayed after restart when updating Firefox to a new version (unless it is desired, hence set up accordingly on server)