Moving XP to ESR?

[Henri Sivonen]

XP has now gone for two years without security patches from Microsoft.
Additionally, as of its latest release, Chrome no longer supports XP.

When 46 ships, it would be a great time to make AUS advertise 45 ESR
builds to XP (even on non-ESR) channel. This would keep XP supported
through the ESR cycle but would put an end to the XP tax on trunk.

Are we already on track to doing this? If not, why not?

--
Henri Sivonen
hsiv...@hsivonen.fi
https://hsivonen.fi/

[Kyle Huey]

12% of our users are on Windows XP.

- Kyle

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-platform
>

[Thomas Zimmermann]

Am 18.04.2016 um 15:18 schrieb Kyle Huey:
> 12% of our users are on Windows XP.

And XP still runs on ~10% of all desktops. That's an opportunity to
convert some of the users to Firefox.

Best regards
Thomas

[Lawrence Mandel]

On Mon, Apr 18, 2016 at 9:04 AM, Henri Sivonen <hsiv...@hsivonen.fi> wrote:

> XP has now gone for two years without security patches from Microsoft.
> Additionally, as of its latest release, Chrome no longer supports XP.
>
> When 46 ships, it would be a great time to make AUS advertise 45 ESR
> builds to XP (even on non-ESR) channel. This would keep XP supported
> through the ESR cycle but would put an end to the XP tax on trunk.
>
> Are we already on track to doing this? If not, why not?
>

We are not on track to do this.

The Firefox Product team is investigating Firefox use on XP in order to
make a decision about the criteria that need to be met to continue to
support this OS. No decision has been made about a change in support for
Windows XP.

Lawrence

[Henri Sivonen]

On Mon, Apr 18, 2016 at 4:18 PM, Kyle Huey <m...@kylehuey.com> wrote:
> 12% of our users are on Windows XP.

That's been getting lower all the time, right? With the current
trajectory, what's the expected percentage at the time when the 45 ESR
would go out of support (assuming normal ESR cycle length)?

[Steve Fink]

Past performance is not an indicator of future results. :)

I don't see how we can estimate the trajectory of XP usage when we have
the discontinuity from Chrome removing XP support. I would expect an
uptick in our XP percentage as a result. How much of an uptick, I have
no idea.

Nor do I know how we want to balance the XP equation -- supporting XP
means putting users at risk by allowing them to continue running an
insecure OS. And yet, a substantial number people will continue to run
XP with or without us, and abandoning them isn't doing them any favors
either.

But if we're going to use number of users as a metric in the decision, I
think we'd have to wait to see the effects of the end of Chrome support.

XP users also aren't going to be the early adopters and thought leaders,
so I would think that x% of XP users is less valuable than x% of Windows
10 users. (Although they may be a more loyal x%, given their lack of
options and resistance to change...)

[Milan Sreckovic]

What’s the “XP tax”? Graphics usually tries to simplify the playing field as much as possible, but I can’t say that XP has been causing any trouble, or that we have been getting too many XP specific problems (certainly fewer than Windows 10 :)

I don’t see XP going away soon, and as mentioned, may even go up.
—
- Milan

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org <mailto:dev-pl...@lists.mozilla.org>
> https://lists.mozilla.org/listinfo/dev-platform <https://lists.mozilla.org/listinfo/dev-platform>

[Chris Peterson]

On 4/18/16 6:46 AM, Thomas Zimmermann wrote:
> Am 18.04.2016 um 15:18 schrieb Kyle Huey:
>> > 12% of our users are on Windows XP.
> And XP still runs on ~10% of all desktops. That's an opportunity to
> convert some of the users to Firefox.

If we want to convert some Chrome XP users, we could run a small social
media promotion to inform them that Firefox still supports XP.
Otherwise, how would they know?

OTOH, if an XP users doesn't mind running an unpatched OS, then they
probably won't care/know about running an unpatched Chrome browser.

[Kartikaya Gupta]

On Mon, Apr 18, 2016 at 2:02 PM, Chris Peterson <cpet...@mozilla.com> wrote:
>
> OTOH, if an XP users doesn't mind running an unpatched OS, then they
> probably won't care/know about running an unpatched Chrome browser.
>

>From data that Chris H-C posted in some previous thread, we know that
Firefox users on XP are using recent versions of Firefox. I suspect
Chrome users on XP are probably also using recent versions of Chrome,
and may care about staying up-to-date.

kats

[Thomas Zimmermann]

Hi

Am 18.04.2016 um 20:02 schrieb Chris Peterson:
> On 4/18/16 6:46 AM, Thomas Zimmermann wrote:
>> Am 18.04.2016 um 15:18 schrieb Kyle Huey:
>>> > 12% of our users are on Windows XP.
>> And XP still runs on ~10% of all desktops. That's an opportunity to
>> convert some of the users to Firefox.
>
> If we want to convert some Chrome XP users, we could run a small
> social media promotion to inform them that Firefox still supports XP.
> Otherwise, how would they know?

True. Maybe get a blog post out, clarifying that Firefox continues to
support XP for the next N years. News sites will spread the word.

>
> OTOH, if an XP users doesn't mind running an unpatched OS, then they
> probably won't care/know about running an unpatched Chrome browser.

There's HW support and requirements of the new OS. And a new OS costs
money, a new browser doesn't.

Best regards
Thomas

[Aryeh Gregor]

On Mon, Apr 18, 2016 at 9:02 PM, Chris Peterson <cpet...@mozilla.com> wrote:
> OTOH, if an XP users doesn't mind running an unpatched OS, then they
> probably won't care/know about running an unpatched Chrome browser.

Gmail nags you if you use an outdated Chrome version. I know someone
who asked me to take a look at their computer because Gmail had a
banner at the top for a few months saying their browser was outdated.
Turns out they were using 32-bit Linux, which Chrome no longer
supports, so I advised them to upgrade to 64-bit at their convenience.

[Nils Ohlmeier]

> On Apr 18, 2016, at 09:56, Milan Sreckovic <msrec...@mozilla.com> wrote:
>
> What’s the “XP tax”? Graphics usually tries to simplify the playing field as much as possible, but I can’t say that XP has been causing any trouble, or that we have been getting too many XP specific problems (certainly fewer than Windows 10 :)

Well as we still have to compile for XP there are certain API’s which we can’t use like here:
https://dxr.mozilla.org/mozilla-central/source/media/mtransport/third_party/nICEr/src/stun/addrs.c#228

The good news is that dxr does not find anything using IsXPSP3OrLater(). But this looks like we have a bit of version specific code in our tree:
https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true

And on top of that come the costs for maintaining XP machines as part of the treeherder setup.

So it is not easy to quantify, but there is a “XP tax” we pay.

Regards
Nils

[Ted Mielczarek]

On Tue, Apr 19, 2016, at 04:14 PM, Nils Ohlmeier wrote:
> The good news is that dxr does not find anything using IsXPSP3OrLater().
> But this looks like we have a bit of version specific code in our tree:
> https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true

FYI, the "XP" here means "cross-platform", and XP_WIN is set whenever
we're building for Windows.

> And on top of that come the costs for maintaining XP machines as part of
> the treeherder setup.
>
> So it is not easy to quantify, but there is a “XP tax” we pay.

This is true. We hit this with toolchain support, we're actively jumping
through hoops to continue targeting XP with newer versions of MSVC.

-Ted

[Kyle Huey]

We jump through some hoops to support things like Linux and Mac too, and
those platforms combined have far fewer users than XP.

- Kyle

[yuhong...@hotmail.com]

That is why I asked about killing XP SP2 in the first place. This brings it in line with what MS officially supported in VS2013 and VS2015. I wonder how much of the marketshare is likely XP SP2.

[Makoto Kato]

On 2016/04/20 5:14, Nils Ohlmeier wrote:
>
>> On Apr 18, 2016, at 09:56, Milan Sreckovic <msrec...@mozilla.com> wrote:
>>
>> What’s the “XP tax”? Graphics usually tries to simplify the playing field as much as possible, but I can’t say that XP has been causing any trouble, or that we have been getting too many XP specific problems (certainly fewer than Windows 10 :)
>
> Well as we still have to compile for XP there are certain API’s which we can’t use like here:
> https://dxr.mozilla.org/mozilla-central/source/media/mtransport/third_party/nICEr/src/stun/addrs.c#228
>
> The good news is that dxr does not find anything using IsXPSP3OrLater(). But this looks like we have a bit of version specific code in our tree:
> https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true

You should query using IsWin2003OrLater() instead.

Also, if we support Vista+ only, we can remove some LoadLibrary() to use
Vista+ API.


-- Makoto

[Makoto Kato]

On 2016/04/20 5:14, Nils Ohlmeier wrote:
>

>> On Apr 18, 2016, at 09:56, Milan Sreckovic <msrec...@mozilla.com> wrote:
>>
>> What’s the “XP tax”? Graphics usually tries to simplify the playing field as much as possible, but I can’t say that XP has been causing any trouble, or that we have been getting too many XP specific problems (certainly fewer than Windows 10 :)
>
> Well as we still have to compile for XP there are certain API’s which we can’t use like here:
> https://dxr.mozilla.org/mozilla-central/source/media/mtransport/third_party/nICEr/src/stun/addrs.c#228
>
> The good news is that dxr does not find anything using IsXPSP3OrLater(). But this looks like we have a bit of version specific code in our tree:
> https://dxr.mozilla.org/mozilla-central/search?q=XP_WIN&redirect=false&case=true

[Mike Conley]

The people on this thread might find chutten's recent blog post interesting:

https://chuttenblog.wordpress.com/2016/04/19/firefoxs-windows-xp-users-upgrade-path/

Juicy chunk: "Between 40% and 53% of Firefox users running Windows XP
are Stuck"

-Mike

[Chris H-C]

> I wonder how much of the marketshare is likely XP SP2.

According to the longitudinal dataset, SP2 is roughly 16% of the Windows XP
population, with the rest SP3. So, still some millions of users.

:chutten

> _______________________________________________
> dev-platform mailing list
> dev-pl...@lists.mozilla.org

> https://lists.mozilla.org/listinfo/dev-platform
>

[Henri Sivonen]

On Mon, Apr 18, 2016 at 4:46 PM, Thomas Zimmermann
<tzimm...@mozilla.com> wrote:
> And XP still runs on ~10% of all desktops. That's an opportunity to
> convert some of the users to Firefox.

This assumes that

1) users who are still on XP still make active browser choices
2) ESR wouldn't be good enough to for these users
3) XP will still run ~10% of desktops in 11 months.

(FWIW, StatCounter puts XP's Web usage share of desktop closer to 7% than 10%.)

On Mon, Apr 18, 2016 at 7:56 PM, Milan Sreckovic <msrec...@mozilla.com> wrote:
> What’s the “XP tax”?

It's our attention being diverted to being backward-looking instead of
forward-looking by a thousand cuts. Here are some examples off the top
of my head:

* We don't have EME-style DRM on XP, but if we hadn't even tried to
accommodate XP, we could have avoided some grief. (For obvious
reasons, I'm not going to elaborate on this on this list.)

* The Rust team has had to do extra work to support XP, since XP is a
Firefox product requirement.

* Lack of SSE2, though not an XP problem per se, coincides with XP,
so we could just require SSE2 if we didn't support XP.

* XP failing to preserve register state on newer CPUs caused an
investigation like
https://bugzilla.mozilla.org/show_bug.cgi?id=1263495#c13

Obviously, none of the above alone seems decisive, but those are just
a few recent things that I can think of without searching. I'm sure
there are a lots and lots of things, each smallish taken alone, but
they add up and take our collective attention away from making our
product better on current systems. Moving XP to ESR would liberate us
from thinking of some of them, but, granted, we might feel compelled
to figure out stuff like the AVX thing even on ESR. Also, some of the
above are sunk cost now, but my point is that as long as XP is treated
as supported, it can inflict new analogous costs on us.

On Tue, Apr 19, 2016 at 11:24 PM, Kyle Huey <m...@kylehuey.com> wrote:
> We jump through some hoops to support things like Linux and Mac too, and
> those platforms combined have far fewer users than XP.

Linux and Mac will still be as relevant in 11 months. XP's relevance
is declining. If our estimate was that XP won't be worthwhile in 11
months, putting it on ESR now would make sense compared to expending
the effort of full support over the next 11 months.

[Armen Zambrano G.]

Would it make more sense to have a relbranch instead of using ESR?
IIRC ESRs are stable for a period but when we uplift we uplift
everything new.
For this XP relbranch we would only take security patches.

It would serve the purpose of keeping our users secure where they're but
saving some energy in making new features also XP compatible.

Setting an N months EOL expectation (plus another criteria[s]) might be
wise rather than leaving it open ended.

regards,
Armen

Zambrano Gasparnian, Armen
Automation & Tools Engineer
http://armenzg.blogspot.ca

[Armen Zambrano G.]

Would it make more sense to have a relbranch instead of using ESR?
IIRC ESRs are stable for a period but when we uplift we uplift
everything new.
For this XP relbranch we would only take security patches.

It would serve the purpose of keeping our users secure where they're but
saving some energy in making new features also XP compatible.

Setting an N months EOL expectation (plus another criteria[s]) might be
wise rather than leaving it open ended.

regards,
Armen

On 16-04-20 11:46 AM, Henri Sivonen wrote:

[Ben Hearsum]

This would require a new update channel to support, because it would be
a unique line of code that isn't "release" or "esr".

It couldn't be implemented as a relbranch either, because we'd need CI
for it. You're basically proposing a long lived esr-like branch that we
only ship to XP users.

I suspect that backporting to this would get very difficult very
quickly. We'd be better off moving XP to ESR IMO.

[Chris H-C]

> * Lack of SSE2, though not an XP problem per se, coincides with XP,
so we could just require SSE2 if we didn't support XP.

We have data about this. Unfortunately we'd also have to kick out some
Windows 7 users. For every ten WinXP Firefox users without SSE2 we have a
Win7 Firefox user without SSE2.

In "real numbers" we're looking at fractions of a million users, say
somewhere on the order of 100k Firefox users on Windows 7 have no SSE2.

(there may also be some tens or hundreds of Linux users, but with sizes so
small I don't have confidence in the numbers produced).

:chutten

[Daniel Veditz]

On 4/20/16 11:53 AM, Armen Zambrano G. wrote:
> Would it make more sense to have a relbranch instead of using ESR?

Oh lordy, no! It's hard enough diverting engineering work to supporting
a single ESR 9 months after the fork. Why would we do two of them? How
would a relbranch differ from ESR?

> IIRC ESRs are stable for a period but when we uplift we uplift
> everything new.
> For this XP relbranch we would only take security patches.

That's what we do with an ESR: security and stability patches only. In
practice not many stability patches once it's in decent shape after the
first couple releases--only if one of the security patches breaks
something. We don't uplift things to ESR, ESRs reach their end-of-life
and then people migrate to the next ESR.

> It would serve the purpose of keeping our users secure where they're but
> saving some energy in making new features also XP compatible.
>
> Setting an N months EOL expectation (plus another criteria[s]) might be
> wise rather than leaving it open ended.

Putting XP people on an existing ESR does both those things. It's the
second that's problematic. When the ESR we've diverted the XP folks to
dies, what then? If we still have a significant chunk of XP users they
will have nowhere to go. We could try to extend the life of that ESR,
but that could result in more work back-porting fixes and
building/testing/shipping extra releases than simply working around XP
issues until ESR 52 next year.

-Dan Veditz

[Jonathan Kew]

On 20/4/16 20:14, Ben Hearsum wrote:
> This would require a new update channel to support, because it would be
> a unique line of code that isn't "release" or "esr".
>
> It couldn't be implemented as a relbranch either, because we'd need CI
> for it. You're basically proposing a long lived esr-like branch that we
> only ship to XP users.
>
> I suspect that backporting to this would get very difficult very
> quickly. We'd be better off moving XP to ESR IMO.
>

I think you're right about that.

What we should keep in mind, though, is that if we decide to move XP
users to ESR now, we are in effect making the decision to end support
for them altogether in a year (when the ESR we've moved them to reaches
EOL). At that point, the next ESR will be based on a mozilla-central
that has long since abandoned XP, and there's no chance that we'll
somehow magically backport it; nor, I think, will there be any appetite
for extending the life of ESR45 beyond its normal term.

So the question we need to ask ourselves, before making a decision to
move XP users to ESR, is whether we're prepared to commit ourselves
_now_ to an EOL date roughly a year away, regardless of how XP usage
develops over the coming year.

My hunch is that XP usage will decline pretty slowly, and I'm not very
comfortable with making decisions now that imply we'll be abandoning
those users in a year.

JK