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.

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.

(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.

(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

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.

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

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

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.

(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.

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

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?

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

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).

(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? >

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.

(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

(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.

(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.

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

QA will need to track this bug.

This is FIXED - addressing the followup issues in bug 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)