The default bug view has changed. See this FAQ.

Block updates to de-supported Windows versions at switch to Visual C++ 2010

VERIFIED FIXED

Status

Release Engineering
Other
P2
normal
VERIFIED FIXED
6 years ago
4 years ago

People

(Reporter: nthomas, Assigned: nthomas)

Tracking

(Blocks: 1 bug)

other
x86
Windows XP
Dependency tree / graph

Firefox Tracking Flags

(firefox13+ verified)

Details

Attachments

(1 attachment, 1 obsolete attachment)

(Assignee)

Description

6 years ago
Bug 668436 has information on versions to block, this is just for the config file changes. Would need to figure out if 64bit XP needs blocking too, QA may be able to help.

Best case is deploying the AUS config on the day we swap to the new compiler, so that we don't brick anyone's Nightly. Once bug 668436 lands, we'll be able to tell how many users are affected.

Needs the AUS code changes in bug 666735 to target minor updates for end users, and nightlies.
(Assignee)

Comment 1

5 years ago
Created attachment 578956 [details] [diff] [review]
[cvs] wip config change

This is the sort of thing we'd want to block updates for Win 2000, Win XP RTM and SP1, assuming we make the switch while Firefox 11 is in nightly. Untested at this point.
Another option:
Coordinate this with the LTS release, so that we can switch users on SP1 or lower to the LTS release, giving them 12 more months of security fixes "for free" until they can install SP2 or later. This would mean that, if the LTS release is Firefox 12, that we should start doing this for Firefox 12 too.
Keywords: sec-review-needed
This might not be necessary by switching to VS2010.  See bug 563318 comment 24.
removing sec-review-needed, we might care about the text displayed but not this directly
Keywords: sec-review-needed

Updated

5 years ago
Duplicate of this bug: 721809
(Assignee)

Comment 6

5 years ago
Are we planning to switch to VS 2010 early in the 13.0 cycle then ?
(In reply to Nick Thomas [:nthomas] from comment #6)
> Are we planning to switch to VS 2010 early in the 13.0 cycle then ?

Yes.
(Assignee)

Updated

5 years ago
Assignee: nobody → nrthomas
Priority: P3 → P2
Created attachment 593185 [details] [diff] [review]
nthomas's patch updated for 13.0a1+

Updated version number to reflect current trunk version. Don't believe nthomas has tested this yet.

(MSVC2010 switch landed today, so if we are concerned about Win2k/pre WinXP sp2 Nightly users receiving updates that won't function - this needs to be landed before the next m-c Nightly is generated.)
Attachment #578956 - Attachment is obsolete: true
(In reply to Ed Morley [:edmorley] from comment #8)
> Created attachment 593185 [details] [diff] [review]
> nthomas's patch updated for 13.0a1+
> 
> Updated version number to reflect current trunk version. Don't believe
> nthomas has tested this yet.
> 
> (MSVC2010 switch landed today, so if we are concerned about Win2k/pre WinXP
> sp2 Nightly users receiving updates that won't function - this needs to be
> landed before the next m-c Nightly is generated.)

It bounced unfortunately.

Note that without this, the update experience would be that when you restart your browser, you will get a dialog saying that function foo could not be loaded from dll bar, at which point you're done being able to use Firefox unless if you redownload a version which works on your OS.
(Assignee)

Comment 10

5 years ago
We'll definitely get this landed. Can anyone confirm the OS's we want to block are correctly included in attachment 593185 [details] [diff] [review] ?
(Assignee)

Comment 11

5 years ago
(In reply to Nick Thomas [:nthomas] from comment #10)
> We'll definitely get this landed. Can anyone confirm the OS's we want to
> block are correctly included in attachment 593185 [details] [diff] [review] ?

Landed when 2010 sticks, that is. I don't have those OS to test directly, but I can deploy the patch to a testing update server and munge URLs.
(Assignee)

Comment 12

5 years ago
ashughes, with your Win2K VM could you try this:

1, setup and enable an mpt-vpn connection (need to reach aus2-staging.m.o on an internal IP)
2, install http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2012/01/2012-01-30-03-11-42-mozilla-central/firefox-12.0a1.en-US.win32.installer.exe
3, set app.update.url.override to
http://aus2-staging.mozilla.org/update/3/%PRODUCT%/%VERSION%/%BUILD_ID%/%BUILD_TARGET%/test/%CHANNEL%/%OS_VERSION%/%DISTRIBUTION%/%DISTRIBUTION_VERSION%/update.xml
4, check for updates

None should be found. (The testing setup is a production aus + attachment 593185 [details] [diff] [review]; the current update for en-US locale duplicated to 'test', with the version bumped from 12.0a1 to 13.0a1 so the patch kicks in).

If anyone lurking on this bug has XP RTM or XP SP1 available and can try that too that'd be great.
(Assignee)

Comment 13

5 years ago
Against that test server the following do not return an update with the patch (but do without):
http://aus2-staging.mozilla.org/update/3/Firefox/12.0a1/20120130031142/WINNT_x86-msvc/test/nightly/Windows_NT 5.0.4.0 (x86)/default/default/update.xml
http://aus2-staging.mozilla.org/update/3/Firefox/12.0a1/20120130031142/WINNT_x86-msvc/test/nightly/Windows_NT 5.1.0.0 (x86)/default/default/update.xml
http://aus2-staging.mozilla.org/update/3/Firefox/12.0a1/20120130031142/WINNT_x86-msvc/test/nightly/Windows_NT 5.1.1.0 (x86)/default/default/update.xml

and these still do:
http://aus2-staging.mozilla.org/update/3/Firefox/12.0a1/20120130031142/WINNT_x86-msvc/test/nightly/Windows_NT 5.1.2.0 (x86)/default/default/update.xml
http://aus2-staging.mozilla.org/update/3/Firefox/12.0a1/20120130031142/WINNT_x86-msvc/test/nightly/Windows_NT 5.1.3.0 (x86)/default/default/update.xml
http://aus2-staging.mozilla.org/update/3/Firefox/12.0a1/20120130031142/WINNT_x86-msvc/test/nightly/Windows_NT 6.0.2.0 (x86)/default/default/update.xml
http://aus2-staging.mozilla.org/update/3/Firefox/12.0a1/20120130031142/WINNT_x86-msvc/test/nightly/Windows_NT 6.1.1.0 (x64)/default/default/update.xml
(Assignee)

Updated

5 years ago
Attachment #593185 - Flags: review?(rail)
Attachment #593185 - Flags: review?(rail) → review+
(In reply to Nick Thomas [:nthomas] from comment #12)
> ashughes, with your Win2K VM could you try this:
> 
> 1, setup and enable an mpt-vpn connection (need to reach aus2-staging.m.o on
> an internal IP)

Sadly, I don't think I have MPT access. Anyone in QA with MPT access should be able to test this for you. The VM is available to everyone.
Nevermind, I just got access. I will see if I can test this now.
Tested as per comment 13 on Windows 2000, no update found.
(Assignee)

Comment 17

5 years ago
Anthony, that's great! Could you reset app.update.url.override and verify an update is found ? Should be the 2012-01-31 nightly, which will still run.

I've got an XP RTM VM setup now and will test that and SP1.
(In reply to Nick Thomas [:nthomas] from comment #17)
> Anthony, that's great! Could you reset app.update.url.override and verify an
> update is found ? Should be the 2012-01-31 nightly, which will still run.
> 
> I've got an XP RTM VM setup now and will test that and SP1.

Confirmed. Resetting the pref downloads 2012-01-31.
(Assignee)

Comment 19

5 years ago
Great. Looks like XP is working too in a quick check. I'll verify that and get the AUS patch deployed today.
(Assignee)

Comment 20

5 years ago
Comment on attachment 593185 [details] [diff] [review]
nthomas's patch updated for 13.0a1+

Verified working on XP RTM and SP1, and no effect on XP SP3.

Checking in config-dist.php;
/cvsroot/mozilla/webtools/aus/xml/inc/config-dist.php,v  <--  config-dist.php
new revision: 1.187; previous revision: 1.186
done

$ cvs tag AUS2_PRODUCTION config-dist.php
W config-dist.php : AUS2_PRODUCTION already exists on version 1.186 : NOT MOVING tag to version 1.187
$ cvs tag -F AUS2_PRODUCTION config-dist.php
T config-dist.php
Attachment #593185 - Flags: checked-in+
(Assignee)

Updated

5 years ago
Depends on: 723348
(Assignee)

Comment 21

5 years ago
Verified working in production.
Status: NEW → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED

Updated

5 years ago
tracking-firefox13: --- → +
Blocks: 723613
Blocks: 467530

Updated

5 years ago
status-firefox13: --- → fixed
QA tested this a while back but I neglected to update the bug. Marking verified.
Status: RESOLVED → VERIFIED
status-firefox13: fixed → verified
Just for posterity, I realized I never applied this to SeaMonkey's aus2. And I just manually applied that now for 2.10a1+
Product: mozilla.org → Release Engineering
You need to log in before you can comment on or make changes to this bug.