Stop advertising Firefox updates to clients without SSE2

RESOLVED FIXED

Status

Release Engineering
Releases
RESOLVED FIXED
2 years ago
a year ago

People

(Reporter: gps, Assigned: bhearsum)

Tracking

(Depends on: 1 bug)

unspecified
Dependency tree / graph

Firefox Tracking Flags

(firefox49blocking fixed)

Details

(Reporter)

Description

2 years ago
Firefox (48 or 49 TBD) will require SSE to run. The update server should be configured to not serve updates to clients that don't support SSE.

We don't currently advertise SSE support in the update URL/ping. Bug 1271761 tracks adding that.
(Assignee)

Comment 1

2 years ago
N
(Assignee)

Comment 2

2 years ago
(In reply to Ben Hearsum (:bhearsum) from comment #1)
> N

Oops. I was going to write a comment here, but ended up doing so in bug 1271761.

Updated

2 years ago
Summary: Stop advertising Firefox updates to clients without SSE → Stop advertising Firefox updates to clients without SSE2
Blocks: 1274196
What's about adding a SSE2-Check in the download-routine in the about-dialog and display instead that a download is ready to download/gets downloaded/FF needs a restart a error msg that there will be no new updates that run on systems without SSE2-Support?
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #3)
> What's about adding a SSE2-Check in the download-routine in the about-dialog
> and display instead that a download is ready to download/gets downloaded/FF
> needs a restart a error msg that there will be no new updates that run on
> systems without SSE2-Support?

I see in bug 1271761 discussions about future requirements...
So maybe such a error msg can be later expand to other requirements, too.
(Assignee)

Comment 5

2 years ago
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #3)
> What's about adding a SSE2-Check in the download-routine in the about-dialog
> and display instead that a download is ready to download/gets downloaded/FF
> needs a restart a error msg that there will be no new updates that run on
> systems without SSE2-Support?

The updater doesn't support this. It can either install a MAR, or show a message about why there's no updates available. I'll defer to others on whether or not we'd want to support this case.
(In reply to Ben Hearsum (:bhearsum) from comment #5)
> (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #3)
> > What's about adding a SSE2-Check in the download-routine in the about-dialog
> > and display instead that a download is ready to download/gets downloaded/FF
> > needs a restart a error msg that there will be no new updates that run on
> > systems without SSE2-Support?
> 
> The updater doesn't support this. It can either install a MAR, or show a
> message about why there's no updates available. I'll defer to others on
> whether or not we'd want to support this case.

Not sure, but I guess there should be something like a class that check pre-requirements at the startup of FF... (at least in future for SSE2.)
...so improving it (also for the future) and give as response error messages that can me used at startup of FF and e.g. when checking for updates...(?)
(Assignee)

Comment 7

2 years ago
(In reply to Tobias B. Besemer [:BesTo] (QA) from comment #6)
> (In reply to Ben Hearsum (:bhearsum) from comment #5)
> > (In reply to Tobias B. Besemer [:BesTo] (QA) from comment #3)
> > > What's about adding a SSE2-Check in the download-routine in the about-dialog
> > > and display instead that a download is ready to download/gets downloaded/FF
> > > needs a restart a error msg that there will be no new updates that run on
> > > systems without SSE2-Support?
> > 
> > The updater doesn't support this. It can either install a MAR, or show a
> > message about why there's no updates available. I'll defer to others on
> > whether or not we'd want to support this case.
> 
> Not sure, but I guess there should be something like a class that check
> pre-requirements at the startup of FF... (at least in future for SSE2.)
> ...so improving it (also for the future) and give as response error messages
> that can me used at startup of FF and e.g. when checking for updates...(?)

Yeah, this might be something to look at for the future, but it's not going to help us here. Can you file a separate bug for this, or start a discussion on the newsgroups?
"Suggestion: Class or API to check pre-requirements of Firefox":
https://groups.google.com/forum/#!topic/mozilla.dev.platform/EqFb9ciKSvk
(Assignee)

Updated

2 years ago
Depends on: 1274374
(Assignee)

Comment 9

2 years ago
Once bug 1271761 is landed, we'll need to create a watershed update for it. People will route through it, and then move on to the latest build from there (assuming they have SSE2 support).
Assignee: nobody → bhearsum
(Assignee)

Comment 10

2 years ago
(In reply to Ben Hearsum (:bhearsum) from comment #9)
> Once bug 1271761 is landed, we'll need to create a watershed update for it.
> People will route through it, and then move on to the latest build from
> there (assuming they have SSE2 support).

Balrog prod is ready to go. I just need to know what the last release to support SSE will be, and I'll set-up the wareshed rule.

Updated

2 years ago
Depends on: 1277359, 1277361
(Assignee)

Comment 11

a year ago
Have we stopped supporting SSE on Nightly (or elsewhere) yet?
Flags: needinfo?(gps)
(Reporter)

Comment 12

a year ago
(In reply to Ben Hearsum (:bhearsum) from comment #11)
> Have we stopped supporting SSE on Nightly (or elsewhere) yet?

According to bug 1271759, yes.
Flags: needinfo?(gps)
(Assignee)

Comment 13

a year ago
(In reply to Gregory Szorc [:gps] from comment #12)
> (In reply to Ben Hearsum (:bhearsum) from comment #11)
> > Have we stopped supporting SSE on Nightly (or elsewhere) yet?
> 
> According to bug 1271759, yes.

As far as I can tell, that patch doesn't make Firefox unrunnable with SSE, just uninstallable. My angle here is that we need to stop updates before we ship something that's actually unrunnable for SSE users. Robert, maybe you know if that has happened yet?
Flags: needinfo?(robert.strong.bugs)

Comment 14

a year ago
A series of patches (including the MSVC2015 upgrade and Rust stuff) have landed which require SSE2. This is effective as of FF49 so we need to have a milestone update to 48 (to get the SSE bits into the update URL) and then prevent non-SSE2 users from updating to 49).
Flags: needinfo?(robert.strong.bugs)

Comment 15

a year ago
Adding tracking flags to make sure this ends up on relman radar.
status-firefox49: --- → affected
tracking-firefox49: --- → blocking
(Assignee)

Comment 16

a year ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #14)
> A series of patches (including the MSVC2015 upgrade and Rust stuff) have
> landed which require SSE2. This is effective as of FF49 so we need to have a
> milestone update to 48 (to get the SSE bits into the update URL) and then
> prevent non-SSE2 users from updating to 49).

Do you know the last Nightly and Dev Edition to support non-SSE2? I was hoping to set-up a watershed rule to avoid updating those folks into oblivion. Maybe it's too late to matter at this point though.
Flags: needinfo?(benjamin)

Comment 17

a year ago
For aurora and up we should make the first 49 release the first bad. That's the release where the installer refuses to install. ~nobody on nightly/aurora had non-SSE2 though, so it's mostly important for beta and release.
Flags: needinfo?(benjamin)
(Assignee)

Comment 18

a year ago
(In reply to Benjamin Smedberg  [:bsmedberg] from comment #17)
> For aurora and up we should make the first 49 release the first bad. That's
> the release where the installer refuses to install. ~nobody on
> nightly/aurora had non-SSE2 though, so it's mostly important for beta and
> release.

OK, we're too late to set this up even for Aurora, we don't have the metadata for the last 48.0 aurora nightly anymore.

I've filed all the necessary bugs to make sure we set-up watersheds and deprecation rules for beta/release/esr. For future reference:
https://bugzilla.mozilla.org/show_bug.cgi?id=1284902
https://bugzilla.mozilla.org/show_bug.cgi?id=1284901
https://bugzilla.mozilla.org/show_bug.cgi?id=1284903
https://bugzilla.mozilla.org/show_bug.cgi?id=1284905
https://bugzilla.mozilla.org/show_bug.cgi?id=1284904
https://bugzilla.mozilla.org/show_bug.cgi?id=1284906
Status: NEW → RESOLVED
Last Resolved: a year ago
Resolution: --- → FIXED
Is this resolved for 49, then? Or is there anything left to do here? 

And, should we be changing something in the system requirements for 49 beta release notes? I'm not sure exactly what to say there so would like help with wording.
Flags: needinfo?(bhearsum)
(Assignee)

Comment 20

a year ago
(In reply to Liz Henry (:lizzard) (needinfo? me) from comment #19)
> Is this resolved for 49, then? Or is there anything left to do here? 
> 
> And, should we be changing something in the system requirements for 49 beta
> release notes? I'm not sure exactly what to say there so would like help
> with wording.

There's still things that need doing as part of the Firefox 48.0 and 49.0 releases (and some ESRs and Betas). The bugs in comment #18 track these, and RelEng release checklists have been updated as well.
Flags: needinfo?(bhearsum)
I'm sort of fuzzy on this bug. Should this report still be: tracking-firefox49: blocking  ?
And comment 18 makes me think 48 is also affected ?
Flags: needinfo?(bhearsum)
(Assignee)

Comment 22

a year ago
(In reply to David Bolter [:davidb] from comment #21)
> I'm sort of fuzzy on this bug. Should this report still be:
> tracking-firefox49: blocking  ?
> And comment 18 makes me think 48 is also affected ?

I think those should probably be moved to version-specific bugs noted in comment #18.
Flags: needinfo?(bhearsum)
status-firefox49: affected → fixed
You need to log in before you can comment on or make changes to this bug.