Last Comment Bug 685727 - Remove What's New page from the Firefox Update Experience.
: Remove What's New page from the Firefox Update Experience.
Status: VERIFIED FIXED
[qa!]
:
Product: Firefox
Classification: Client Software
Component: General (show other bugs)
: 7 Branch
: x86 All
: P3 normal (vote)
: Firefox 9
Assigned To: christian
:
Mentors:
http://www.mozilla.org/en-US/firefox/...
Depends on: 685958
Blocks: 675968
  Show dependency treegraph
 
Reported: 2011-09-08 16:13 PDT by Laura Mesa [:lmesa] [:lvmesa]
Modified: 2011-11-17 07:23 PST (History)
17 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
fixed
fixed
wontfix


Attachments
Update official branding to remove a url so no tab is opened after an update (950 bytes, patch)
2011-09-08 18:51 PDT, christian
no flags Details | Diff | Review
Update official branding to remove a url so no tab is opened after an update, now with less typos! (951 bytes, patch)
2011-09-08 18:52 PDT, christian
gavin.sharp: review+
Details | Diff | Review

Description Laura Mesa [:lmesa] [:lvmesa] 2011-09-08 16:13:55 PDT
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] 2011-09-08 16:20:09 PDT
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] 2011-09-08 16:27:36 PDT
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] 2011-09-08 16:29:32 PDT
Unfortunately, I don't think we can do that until those bugs are resolved.
Comment 4 Laura Mesa [:lmesa] [:lvmesa] 2011-09-08 16:38:33 PDT
(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] 2011-09-08 16:46:56 PDT
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] 2011-09-08 16:56:48 PDT
(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 [:rstrong] (use needinfo to contact me) 2011-09-08 16:58:29 PDT
It could be done in Firefox itself. ccing Gavin
Comment 8 christian 2011-09-08 18:41:35 PDT
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 christian 2011-09-08 18:51:05 PDT
Created attachment 559362 [details] [diff] [review]
Update official branding to remove a url so no tab is opened after an update
Comment 10 christian 2011-09-08 18:52:58 PDT
Created attachment 559363 [details] [diff] [review]
Update official branding to remove a url so no tab is opened after an update, now with less typos!
Comment 11 christian 2011-09-08 18:55:34 PDT
s/less/fewer/...I'm not a savage!
Comment 12 christian 2011-09-08 20:47:42 PDT
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] 2011-09-09 04:30:32 PDT
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: gavin@gavinsharp.com] 2011-09-09 10:05:41 PDT
(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] 2011-09-09 10:26:21 PDT
Just wanted to make sure everyone understood that this would be the case.
Comment 16 Laura Mesa [:lmesa] [:lvmesa] 2011-09-09 10:33:53 PDT
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] 2011-09-09 11:09:53 PDT
here's the bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=685940
Comment 18 christian 2011-09-09 11:21:23 PDT
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] 2011-09-09 11:29:40 PDT
(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 christian 2011-09-09 11:37:37 PDT
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] 2011-09-09 11:39:44 PDT
(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) 2011-09-09 11:45:17 PDT
(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] 2011-09-09 13:54:47 PDT
(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] 2011-09-09 14:04:03 PDT
(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 [:rstrong] (use needinfo to contact me) 2011-09-09 14:26:37 PDT
(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 christian 2011-09-09 15:29:34 PDT
I really think it is just easiest / best to do what's in comment 18
Comment 27 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2011-09-09 15:55:43 PDT
QA will need to track this bug.
Comment 28 :Gavin Sharp [email: gavin@gavinsharp.com] 2011-10-05 16:15:55 PDT
This is FIXED - addressing the followup issues in bug 685958.
Comment 29 Nick Thomas [:nthomas] 2011-10-17 01:53:48 PDT
FTR, this was backed out at bug 689679 comment #6, prior to 8.0b4.
Comment 30 Mihaela Velimiroviciu (:mihaelav) 2011-11-10 08:22:05 PST
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)

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