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

VERIFIED FIXED in Firefox 7

Status

()

Firefox
General
P3
normal
VERIFIED FIXED
6 years ago
6 years ago

People

(Reporter: lmesa, Assigned: christian)

Tracking

7 Branch
Firefox 9
x86
All
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(firefox7 fixed, firefox8 fixed, status1.9.2 wontfix)

Details

(Whiteboard: [qa!], URL)

Attachments

(1 attachment, 1 obsolete attachment)

(Reporter)

Description

6 years ago
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.
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.
Depends on: 459972
OS: Mac OS X → All
Priority: -- → P3
Summary: Remove WN page from the Firefox Update Experience. → Remove What's New page from the Firefox Update Experience.
(Reporter)

Comment 2

6 years ago
To be clear, this is just for the Fx 7 release cycle. We want to have this again with Fx 8.
Unfortunately, I don't think we can do that until those bugs are resolved.
(Reporter)

Comment 4

6 years ago
(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?
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.
(Reporter)

Comment 6

6 years ago
(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?
It could be done in Firefox itself. ccing Gavin
(Assignee)

Comment 8

6 years ago
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.
(Assignee)

Updated

6 years ago
Assignee: nobody → clegnitto
(Assignee)

Updated

6 years ago
Assignee: clegnitto → nobody
Component: Release Engineering → General
Product: mozilla.org → Firefox
QA Contact: release → general
Target Milestone: --- → Firefox 7
Version: other → 7 Branch
(Assignee)

Comment 9

6 years ago
Created attachment 559362 [details] [diff] [review]
Update official branding to remove a url so no tab is opened after an update
Attachment #559362 - Flags: review?(gavin.sharp)
(Assignee)

Comment 10

6 years ago
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!
Attachment #559362 - Attachment is obsolete: true
Attachment #559362 - Flags: review?(gavin.sharp)
Attachment #559363 - Flags: review?(gavin.sharp)
(Assignee)

Updated

6 years ago
Assignee: nobody → clegnitto
(Assignee)

Comment 11

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

Updated

6 years ago
No longer depends on: 459972
Attachment #559363 - Flags: review?(gavin.sharp) → review+
(Assignee)

Comment 12

6 years ago
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
Status: NEW → RESOLVED
Last Resolved: 6 years ago
status-firefox7: --- → fixed
status-firefox8: --- → fixed
Resolution: --- → FIXED
Target Milestone: Firefox 7 → Firefox 9
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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
Resolution: --- → FIXED
Just wanted to make sure everyone understood that this would be the case.
(Reporter)

Comment 16

6 years ago
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?
(Reporter)

Comment 17

6 years ago
here's the bug filed: https://bugzilla.mozilla.org/show_bug.cgi?id=685940
(Assignee)

Comment 18

6 years ago
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).
(Reporter)

Comment 19

6 years ago
(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?
>
(Reporter)

Updated

6 years ago
Depends on: 685958
(Assignee)

Comment 20

6 years ago
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.
(Reporter)

Comment 21

6 years ago
(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).
(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.
(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
(Reporter)

Comment 24

6 years ago
(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.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
(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.
(Assignee)

Comment 26

6 years ago
I really think it is just easiest / best to do what's in comment 18
QA will need to track this bug.
Whiteboard: [qa+]
(Assignee)

Updated

6 years ago
status1.9.2: --- → wontfix
(Reporter)

Updated

6 years ago
Blocks: 675968
This is FIXED - addressing the followup issues in bug 685958.
Status: REOPENED → RESOLVED
Last Resolved: 6 years ago6 years ago
No longer depends on: 685958
Resolution: --- → FIXED
Depends on: 685958
FTR, this was backed out at bug 689679 comment #6, prior to 8.0b4.
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)
Status: RESOLVED → VERIFIED

Updated

6 years ago
Whiteboard: [qa+] → [qa!]
You need to log in before you can comment on or make changes to this bug.