[policy, no patch] Update Drupal's browser support policy

For the record I don't think IE9 issues should hold up release and I'm totally behind the "current stable + 1 previous version" strategy.

The problem however is that many schools, governments and big corporates lag behind in updates. These are markets where Drupal currently (in my experience) has a strong presence. If IE9 is abandoned at release, it might hamper adoption or at the very least lose share in those markets.

I wrote a fairly detailed post yesterday that D.O gobbled up into the ether but here is a short summary of it. Corportations make the move to a new browser very slowly. I work in the Health Care industry and we are just now making the move to standardize on IE9. This is because it is a major undertaking to upgrade 100+ apps that are dependent on a particular version of an Internet browser. Luckily with IE 11, Microsoft is introducing an "Enterprise Mode" that will allow emulation of previous versions of IE to help us out so we can adopt new browsers more rapidly. That being said we have to wait for our vendors to certify that IE 11 will infact work for their product before we can reasonably request that our business users make the move.

One thing that gives our I.T. department leverage to make a browser upgrade is vendor support. We will be following Microsoft's life cycle support so the latest we can abandon IE 9 (and most likely when we will) is when it is no longer supported by Microsoft. See this page for the IE lifecycle http://support2.microsoft.com/lifecycle/search/?sort=PN&alpha=internet+e... and this page for details on the IE support coupled to Windows releases: http://support2.microsoft.com/gp/microsoft-internet-explorer

Hopefully this helps Drupal decide which versions to support based on anticipated Drupal release dates.

@haydeniv: It is precisely due to that slow upgrade process (because of its strictness in mission-critical environments like health care) that catch is arguing that not blocking release of Drupal 8 on IE9 support is not really a problem, because organizations that are slow to upgrade their browsers will surely be slow to adopt Drupal 8. In other words: by the time such organizations consider adopting Drupal 8, they will no longer be using IE9 anymore anyway.
This is not the same as saying we don't support IE9; it's only saying we may ship with known bugs in IE9, but they will get fixed.

Upgrading existing applications is not what I worry about the most. D7 will be supported for at least 2 more years. When consulting on new solutions within the next six months however I would like to start considering D8. Knowing there are known bugs with IE9, not knowing where they might pop up or when they will be fixed makes this harder. This is especially so if the bugs originate from a Drupal subsystem on which contributors will extend, this greatly increases the impact of this issue.

@joostpluijmers
Anyone considering D8 within the next year has a decent dev budget, sounds like a perfect opportunity to get paid time and fix the IE9 bugs for us all :)

@bojanz, ill be sure to factor in those hours ;)

I support the move to treat IE9 bugs as major rather than critical, to reduce the number of Drupal 8 release blocking issues. I agree that unfortunately we need to continue support for IE9 in Drupal 8 for the same reasons as given by @haydeniv in #5, but I think this move would be a sensible compromise.

I know it's a moving target, but would it be useful to list here the currently known Drupal 8 IE9 critical issues that would be downgraded to major if this change was agreed, or right now is it just the one listed related issue ?

We talked about this briefly on our core committer call today. We didn't decide on anything definitive, but one thing we discussed was it was probably better to base whatever standard on browser marketshare versus simply choosing versions, still reserving the right to violate this rule on a case-by-case basis if it made sense for other reasons (e.g. dropping JS support in IE8, despite higher marketshare, for better support of HTML5/mobile in D8).

Discussed this with @Dries, @catch, @webchick, @alexpott, and @xjm. Here's what we came up with:

1. For #13.2, prior to RC, click through test on the latest version of IE, Firefox, Chrome, and Safari.
2. For #13.3, document the oldest versions we "support" in the sense of accepting bug reports for.
3. The priority of a browser-specific bug report will be set based on the same guidelines as https://www.drupal.org/node/45111. E.g., just because something works in IE 11 but doesn't work in IE 9 doesn't make the IE 9 bug critical. It's only critical if we would also consider it critical if it weren't browser-specific.
4. For #13.1, the above definition of critical includes "Renders a system unusable and has no workaround." For an admin-only facing feature, we can say that "use a different browser" is a workaround, which would then classify such a bug as Major or less.
5. For #13.4, we keep the "active test prior to RC" to "latest version". As to when to drop a version from support entirely, we did not discuss that.

Sorry, I was unfortunately pulled away during that discussion so wasn't following it. :\

One additional point on #14.1: we should also add the latest version of mobile browsers to that list.

For #14.2, was there talk of the minimum usage threshold we support for browsers? If not, let's say 5%, for sake of argument. (@todo: We need authoritative sources we can consult for these percentages; we should research what other projects e.g. WordPress, jQuery, etc. use for this)

Based on http://en.wikipedia.org/wiki/Mobile_operating_system#Market_share, Android has 83.1% of smartphone marketshare (54.9% across all phones), iOS has 12.7% marketshare (8.4% across all phones). Next highest is Windows Phone at 3.0% / 2.0%.

So I'd say based on that, with an assumption of 5% marketshare, we should definitely be click-through testing in latest Android built-in browser and latest iOS built-in browser. But we would ignore Windows Phone until/unless it reaches 5%, and we do not care at all about the other ones.

http://en.wikipedia.org/wiki/Usage_share_of_web_browsers is much more confusing, but seems to support the idea that we should care about IE (17.5-59.1%), Chrome (22.7-49.7%), Firefox (11.9%-18%), and Safari (4.7%-14.6%) on desktop.

Based on http://www.netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0 the browser versions we should care about that are > 5% are:

Market Share of Microsoft Internet Explorer 11.0 Microsoft Internet Explorer 11.0 21.79%
Market Share of Microsoft Internet Explorer 8.0 Microsoft Internet Explorer 8.0 19.28%
Market Share of Chrome 39.0 Chrome 39.0 12.79%
Market Share of Microsoft Internet Explorer 9.0 Microsoft Internet Explorer 9.0 9.29%
Market Share of Firefox 34 Firefox 34 6.18%
Market Share of Microsoft Internet Explorer 10.0 Microsoft Internet Explorer 10.0 5.93%

For the most part that follows except for IE 8 (which we decided to not support for technical reasons) and no version of Safari is in that list (but it has just barely enough for us to consider it supported).

Adding a related issue to show that it's definitely not just IE. The bug referenced is in Views UI which to me would fall into the site admin category and it would be great if we could support the latest stable and one previous version rather than adding temporary workarounds.

+1 to what has been added to the issue summary, I'm liking that direction.

#1030090: Document our browser support list is an older issue that looks very closely related.

For security, support all versions the browser vendors themselves support.

I think that makes sense in terms of when Security Advisories should be issued (i.e. when the security team should be involved). But I think security issues for older browsers could still make sense to fix publicly (on a case-by-case basis) depending on impact.

I might be wrong but I think there may even still be security code in Drupal core that targets IE5 and I wouldn't advocate ripping it out unless it's causing some other actual harm...

The current documentation on this is a bit of a mess:

1. https://www.drupal.org/node/1569578 says that Drupal 8 supports older versions of IE from a functional perspective (though not an aesthetic one)
2. https://www.drupal.org/node/61509 and https://www.drupal.org/node/367318 are semi-conflicting documentation pages about this, and both talk about supporting some pretty old browsers.

Here is some informal data on browser support for some popular cms and websites. What comes out is that services either support the latest releases of browsers (IE11), or they support latest releases and n-1 in which case they usually support IE9+ too. There doesn't appear to be a middle ground.

As far as data is concerned here is some up to date info:

Netmarketshare, august 2016

• Chrome 52.0 : 23.96%
• Microsoft Internet Explorer 11.0 : 17.74%
• Chrome 51.0 : 10.55%
• Chrome 45.0 : 5.72%
• Microsoft Edge 13 : 4.20%
• Microsoft Internet Explorer 8.0 : 4.16%
• Chrome 49.0 : 3.21%
• Firefox 47 : 3.14%
• Safari 9.1 : 2.95%
• Microsoft Internet Explorer 9.0 : 2.78%
• Firefox 48 : 1.93%
• Microsoft Internet Explorer 10.0 : 1.83%
• Chrome 47.0 : 1.39%
• Chrome 50.0 : 1.22%
• Chrome 38.0 : 0.97%
• Chrome 43.0 : 0.84%
• Chrome 36.0 : 0.74%
• Microsoft Edge 14 : 0.66%
• Opera 39 : 0.62%
• Microsoft Internet Explorer 7.0 : 0.61%
• Chrome 42.0 : 0.57%

caniuse (statcounter)

It's interesting because they include all devices, which makes chrome on android at 20% market share the rest being far behind making almost all IE/firefox/opera negligible.

stetic, september 2016

no IE10, and IE9 below 2%

IE9 is below IE8 which we don't support. IE10 is gone. This supports the move to support only latest browser version. While looking around I ended up on browse happy which appears to come from wordpress, looks like a good list to me. As far as mobile is concerned, by targeting android 4.4+ we'd cover 81% of all android phones. Which sounds good enough. No idea for IOs, but it doesn't matter much most people update and the market share is tiny compared to android.

On the topic of admin/public requirements, if we go with latest releases we don't need to separate the requirements which would be better (in my spreadsheet only magento separated requirements).

To sum up my position:

1. agreed with the 3 categories of support (A, B, C list)
2. given marketshare and the fact that microsoft itself only support IE11 in A list, have IE10 IE9 in B list and the rest in C list
3. latest release of browsers are A list, n-1 are B list

From the other issue: #1030090-29: Document our browser support list

(http://quirksmode.org/presentations/Autumn2015/webplatforms_visma.pdf slide 42).

A-list browsers are the ones you guarantee the application to work in.
B-list browsers (optional) are the ones you consider likely to run the entire application and/or they lack a few non-essential features.
C-list browsers are all other browsers; you don’t make any guarantees, but they’ll at least be able to view the HTML.

An exemple: https://wiki.mozilla.org/Support/Browser_Support

So B list wouldn't mean necessarily mean we can't beak it. Was trying to be not too harsh but putting IE10- on C list is even better. One thing that might decide for us though is jQuery UI: they support IE11 and n-1 releases: https://jqueryui.com/browser-support/ so… We currently use 1.11, which support IE8+ but according to our third party update policy we should bump the version: #2533498: Update jQuery to version 3.

Opera should definitely be on the A list. But latest Opera is webkit so there is no real challenge.

Android 4 is the new IE6 so not going anywhere for a long while.

That's mozilla take on it, we could mean something else. If/when #2809281: Use ES6 for core JavaScript development goes anywhere it'll be easier for projects to include polyfills if they need older IE support;

A quick thought on mobile browsers: it may be worth considering the cases where traffic is proxied by an external service (in order to optimise the page-load time).

The examples I know of are:

• Opera mini
• Google Web Light
• Mobile networks transparent proxies (for data/image compression)

Each of these will typically alter data before it reaches the browser, so it may be worth treating these as a separate category of browser when thinking about support.

It's also worth considering that these tools may have higher levels of use in specific markets (for example, Google Web Light is targeted at developing countries with slow internet, with Indonesia cited as an example). My current client's site has around 1.6% traffic via Google Web Light, with 100% of that traffic from India.

Opera mini is trying to move away from server-side render and use something less drastic and more compatible, in any case we have #2119299: Make sure Drupal 10 works with mobile proxy browsers.

Allow me to ask a quick question. If we make the deal, will it land in D8.3/4 or D9 ?

Here're browsers data from Baidu stats. (statcounter / netmarketshare in China)
http://tongji.baidu.com/data/browser
(Use Google translation :))

Can you make a screenshot? no flash on my laptop can't see the data.

I knew people in China they have many browsers installed. They may not use the Chrome/Chromium-based daily, but they will switch over when they ran into display errors. the Chromium-based browser is running 2 engine also ( Chromium + IE )

FYI, if I'm reading https://support.microsoft.com/en-us/lifecycle?forceorigin=esmc#gp/Micros... correctly, then at the moment, Microsoft is only providing IE security updates on Windows desktop operating systems for IE11. Except for Windows Vista, for which they're still providing security updates for IE9. But according to https://support.microsoft.com/en-us/help/13853/windows-lifecycle-fact-sheet, they're ending even their extended support of Vista on April 11, 2017. Meanwhile, https://www.drupal.org/core/release-cycle-overview#dates lists the 8.3.0 release date to be April 5, 2017.

So Drupal 8.3.0 might be a great time to drop IE9 and IE10, if we're willing to do so 6 days before Microsoft does. Deciding on this is relevant at least for #2809427: Update jQuery UI to 1.12 and likely other issues to come.

We discussed this on a call with Drupal 8 core committers.

Per #35, we think it's reasonable to drop IE9 and IE10 support starting in Drupal 8.3.

Determine if versions of internet explorer should be considered as 'major' in their own right

We think we should consider IE and Microsoft Edge as 2 different browsers. And as long as within IE, we only support IE 11, then this question is moot. Other parts of the IS that refer to this question could therefore be cleaned up.

For security, support all versions the browser vendors themselves support.

It's unclear whether this quote implies the converse: that we should stop providing security fixes for IE8 now, and for IE9/10 after April 11, 2017. We'd like to remove such an implication from this issue's scope. Per #21, we still have code in Drupal that implements security fixes that are only applicable to IE versions that have long been abandoned by Microsoft. And the issue in #36 continues to be open rather than "won't fix". We need a separate issue for deciding if/when to "won't fix" such issues and/or remove legacy security fixes.

Setting to "Needs work" and tagging for an issue summary update to reflect all this.

Comment #37 reflects consensus among the Drupal 8 core committers during our last call. The following comment is something we did not discuss, so it's just my personal comment:

For site building UIs, only support the most recent version of each major browser...For content UIs, only support the most recent version of each major browser and one back.

I don't think this makes much sense across the different browsers, as each browser follows a different process for distributing and supporting releases:

• For Chrome, new versions come every 6 weeks or so, and the previous one is immediately unsupported by Google. Given this, do we want to accept bug reports for the one version back at all? In practice, by the time the bug report gets opened, fixed, and released in the next monthly patch release of Drupal, most likely, it will already be the Chrome version that's 2 back.
• For Firefox, the version that's one back is irrelevant. The ESR version is the relevant one. And in my opinion, all UIs, including the site building ones, should work on both the latest version and the ESR version, since the ESR version is intended for organizations, and in my opinion, people working in those organizations should be able to perform site building tasks as well as content authoring tasks.
• For Safari and Microsoft Edge, I think for both site builders and content authors, what's relevant isn't the one version back, but the latest version available for a supported operating system version. I think at this point, EdgeHtml 14 is available for all versions of Windows, and if that's true, I see no reason to support EdgeHtml 13 for anyone. At some point, EdgeHtml 15 will be released but not yet rolled out to all Windows versions, so at that time supporting 14 and 15 will make sense, but only until that rollout is completed. Similarly for Safari 9/10. Safari 9 is the latest version available for OS 10.9. I'm unclear if OS 10.9 itself is supported by Apple at this time. Apple is dodgy about answering such questions. But if it is, then I think we should support Safari 9 (at least for site visitors and content authors) until it no longer is, regardless of whether that comes before or after Safari 11's release.

Another question related to this is do we only drop support in a minor release? For example, if we release Drupal 8.3, and 2 months later, a particular browser version becomes obsolete by the above standards, or whatever other standards we agree to, then do we drop that support in 8.3 patch releases, or do we continue supporting the obsolete browsers (in addition to the new ones that have come out in that time) until 8.4?

#40,

Last Safari 9 just released 2 months ago:
https://support.apple.com/en-hk/HT201222

I think stats still matter. For example, Edge 13 still have 30% of Edge 14 usages. (0.35% vs 1.1%). We cannot retire them.

The proposed resolution discusses the level of support for different components:

• site building UIs
• security
• content UIs
• site visitor UIs

I'd proposing adding these axes for considering the degree of support for older browsers:

• Visual consistency (does it look the same in different browsers)
• Front-end functional behaviour (does dynamic behaviour such as drag-drop work as expected)
• Back-end functional behaviour

And to muddy the water even further, I'd also consider which layer would need development to support an older browser: core code, the module layer, or the theme layer (with the highest level of support for core code, the least for the theme-layer).

Drupal 7 contains this in the core form-handling code:

    // If a form contains a single textfield, and the ENTER key is pressed
    // within it, Internet Explorer submits the form with no POST data
    // identifying any submit button. Other browsers submit POST data as though
    // the user clicked the first button. Therefore, to be as consistent as we
    // can be across browsers, if no 'triggering_element' has been identified
    // yet, default it to the first button.
    if (!$form_state['programmed'] && !isset($form_state['triggering_element']) && !empty($form_state['buttons'])) {
      $form_state['triggering_element'] = $form_state['buttons'][0];
    }

If support for an older browser could be provided by a developer creating a custom theme, then it seems reasonable to not spend effort in maintaining that in Drupal core. But if it needed a developer to hack core, I would prefer to see that fix in core.

Legacy browser support is currently included in Drupal 8: one example is Unicode::validateUtf8() which specifically mentions IE6.

For what it's worth, as a front-end developer, totally on board with supporting most recent versions of IE11, Edge, Safari, Firefox, Chrome.

Given how Apple tends to manage releases, going one version back on Safari is not unreasonable. That tends to come up in bug fixes prior to launch with client sites. I'm not all that familiar with ESR of Firefox, but sure, that seems to make sense.

The end result of this is less likely to be the old "hey, here's this weird CSS hack I can put in to target an older browser," and more of, "bummer, we'll probably need to be cautious about using a newer CSS feature like object-fit, because IE 11 and Edge don't support it yet." And where possible, use progressive enhancement to provide usable features everywhere, and if there's a good way to do it, an enhanced version for browsers that support it.

While I'm glad to see IE 9 and 10 in the rearview mirror, glad to eventually dump IE11. Supporting an evergreen browser like Edge is so much better in the long run. This isn't a Microsoft bash: I'd like to see Apple get better at more frequent releases.

Anyhow, glad to see consensus from committers on this. Kudos.

I created a child issue for just the IE9/10 decision: #2842298: [policy, no patch] Drop IE9 and IE10 support from Drupal 8.4.x. Please comment there for that as needed.

In #46, I completely rewrote the issue summary to make a much simpler proposal that's similar but slightly different to what was there before. In essence, let's just follow jQuery's lead instead of defining our own segregation of visitor vs author vs builder UIs. Especially since jQuery is used by all three of those user categories, and I don't think we gain much by reducing the supported browsers further for the more advanced UIs. If it turns out that there's a compelling reason to build the more advanced UIs for a reduced browser set, let's open a new issue for discussing that.

This also goes against most of what I wrote in #38, but I'm okay with that. I don't think in practice it will make much difference, and I think aligning with jQuery is simpler and worth it.

I removed the "security" tag from this issue, because I'd like to punt that discussion to a different issue per #3 in this issue's proposed resolution.

From #15:

@todo: We need authoritative sources we can consult for these percentages; we should research what other projects e.g. WordPress, jQuery, etc. use for this

I rewrote this issue to be based on jQuery, so we're good there :)

For WordPress, I can't find where they document browser support other than https://en.support.wordpress.com/browser-issues/ (which is for wordpress.com, not wordpress.org). There they say that some themes won't work with IE10 and below, and that in general they recommend using the latest version of a browser. I don't see where they use browser market share percentage in their policy around this.

For "etc.", I'll point out that:

• Ember chose to retain IE9 support back in 2015, and has continued to retain it in 2.x.
• G Suite has a similar policy as what is proposed in this issue, of Current and Current-1 for most browsers, and only IE11 as proposed in #2842298: [policy, no patch] Drop IE9 and IE10 support from Drupal 8.4.x.
• Facebook is similar to Wordpress.com in recommending the latest and not saying more than that.

I mention the latter two, because even though they're not open-source projects, they have a lot of users, so provide incentive for users to upgrade their browsers.

I think WordPress mostly leaves it up to the theme or plugin to decide what browser versions they support (even within core):
https://github.com/WordPress/twentysixteen/issues/6#issuecomment-136399564
https://core.trac.wordpress.org/ticket/38021

But for basic core admin functionality they try to keep it functional in older browsers (but also don't really focus on older browsers when testing):
https://core.trac.wordpress.org/ticket/18199#comment:24

I think that makes sense and is pretty close to what Drupal does in practice.

Updating https://www.drupal.org/docs/8/system-requirements/browser-requirements to be aggressive about which browser versions are listed there seems fine because it currently has a very high bar for being listed there ("known to work well with Drupal 8 core and support all of its features") and in general it seems fine to say you should update to the newest version of a browser for the best experience.

What's missing from that page is the idea of whether anything is expected to work in older browsers, or whether it just falls off a cliff and you should expect Drupal to potentially be completely non-functional. Which gets into the question of A-list, B-list, C-list browsers in #25. Should that be left to the other issue to discuss, if not here? I think it's pretty important, and as mentioned above I think Drupal may have a de facto split similar to that already.

Also as I mentioned earlier in this issue we really need to fix the documentation to be consistent:
https://www.drupal.org/node/367318
https://www.drupal.org/docs/8/system-requirements/browser-requirements
https://www.drupal.org/docs/7/system-requirements/browser-requirements

Or at the very least, the first should not contradict the last two like it currently does - maybe it should just link to the last two?

I would also support making the 7 and 8 pages more consistent though, at least in terms of the "known to work well with Drupal core and support all of its features" part. (Drupal 7 core probably did once work fully on IE6, but we can't realistically guarantee that it still does or will going forward. We're not going to hold up issues on IE6 testing that will never happen, but if someone really wants to fix an IE6 bug in Drupal 7 core we probably wouldn't stop them either :)

If Drupal dropped older browsers, it's not fixable! We should keep it in mind while making the decision!

WordPress,
There's ZERO WP Core Javascript, Styles & Plugins dependencies for frontend UI. More, you will build a totally new UI. Who use verdor themes? But in Drupal, even you build 100% new UI, usually it loaded 100s scripts & styles from CORE modules and CORE base theme. You use Drupal for complex development.

jQuery,
Just load multiple version. jQuery drop older browsers because they want a lightweight version, not a technical problem or fasten the development. You could not use D7 & D8 together.

Even worse case:
#2842298: [policy, no patch] Drop IE9 and IE10 support from Drupal 8.4.x
There's only one way to go if you're already using D8.2. Or either got hacked!

Less or more, for Google or Facebook..etc
They said drop it. But all main features are workable usually. They may serve older ugly version to users. Basecamp keeps the classic version for very looong period of time! While they drooooping a lot of older browsers.

-------

We should consider to maximum the supports and only use modern API in UI enhances features. For example the outside_in modules, it can turn on and off and won't affect normal usage, I think we able drop IE10/11. It's okay to make a support chart like this: http://hammerjs.github.io/browser-support/

In some cases, even we dropped older browsers, I think we should not rush for ALL new APIs immediately! For example, the CSS FLEXBOX, it looks modern & may fasten the Core development but it's not a MUST feature to make the SAME UI! We can also split it into mobile & desktop. It makes sense to use more modern API in mobile.

Notes:
- Javascript Syntax
There's not much problem if our ES6 process goes smooth (It's bad status at the moment)
Thanks to: https://github.com/babel/babel-preset-env

- Maybe we should look at popular CSS frameworks, they cover a wide range of Javascript usages and frontend patterns.

but if someone really wants to fix an IE6 bug in Drupal 7 core we probably wouldn't stop them either :)

I think I holding around 10 older IE issues with patches. End users moan at issue threads but no Coders to do a review! Top Core contributors always following the CORE route.

Dropping support for old versions of IE is proceeding nicely. See #2842298-33: [policy, no patch] Drop IE9 and IE10 support from Drupal 8.4.x.

Regarding this issue (in other words, all the other browsers), I discussed it with @webchick, and she was not in favor of us aligning our support policy with jQuery's. For one, jQuery defines its "Active support" as "jQuery is constantly tested with all of its supported browsers via unit tests.". But Drupal does not yet have automated browser-specific testing, so for us, "active support" is what developers manually test on, and as far as I know, that's almost exclusively the current version, and almost never the Current-1 or older versions. So I think us stating a policy that we provide "active support" on the Current-1 version would be inconsistent with reality.

Regarding what jQuery means as "unsupported", they say "While jQuery might run without major issues in older browser versions, we ... generally do not fix bugs that may appear in them.". However, @webchick wasn't comfortable with something that vague, especially for old versions that still have a lot of usage, e.g., Chrome 45.

So I think we need to answer questions like:

1. What do we actively test? I think just Current. Or would someone like to make a case for also including Current-1 and how we could actually make good on that?
2. What do we accept and fix bugs for? I think at a minimum Current-1, but should we also go farther back for Chrome and Firefox? E.g., maybe all versions less than a year old? Or all versions with >1% usage? Any other ideas?
3. For above, do we also provide workarounds when the bug is upstream, e.g., in jQuery?
4. When do we actively use a new browser feature? For example, Fetch is supported in all current browsers, but not before Firefox 39 or Chrome 42. What becomes the trigger for when we can use it?

When do we actively use a new browser feature? For example, Fetch is supported in all current browsers, but not before Firefox 39 or Chrome 42. What becomes the trigger for when we can use it?

Oops. That's a poor example, because IE11 doesn't support Fetch. It might be hard to find good examples, because probably anything supported in IE11 has been supported in Chrome and Firefox for a long time now. However, #52 mentions Flexbox, so maybe that's a good example to consider:

1. According to http://caniuse.com/#feat=flexbox, IE11 supports it except for some bugs. Meanwhile, Chrome required the -webkit- prefix for versions 28 and below, and Firefox required the -moz- prefix for versions 21 and below. So, can we start using flexbox without those prefixes? I would argue yes, since those are extremely old versions of Chrome and Firefox. But this highlights the need for us to be clear about how old does a version need to be before we allow intentional breaks.
2. According to the "known issues" in the above link, "Firefox 51 and below does not support Flexbox in button elements. Fixed in version 52."
   Firefox 51 is a much more recent version. So, are we allowed to use Flexbox on button elements? Or would that constitute "actively use a new browser feature", for which we want more time to pass?

I don't have a strong opinion on this particular example, but just trying to provide some concrete cases for us to think about in answering #56.4 more generally.

it looks almost impossible for us to release a Drupal version that relies on a feature not supported by at least one or two previous chrome and firefox releases

But what about Chrome 45 still having 8.4% usage as of last month, despite being almost 2 years and 13 versions obsolete? Seems to me we should probably still accept bug reports and fixes for Drupal bugs on Chrome 45 and not actively use Chrome 46+ features that would hard break on Chrome 45. But per #56.2, I don't know how to best generalize that. Or maybe we shouldn't generalize it, and instead update the minimum Chrome version explicitly with each Drupal minor release, based on usage stats or other compelling considerations?

Safari's release schedule is more opaque though.

Isn't it pretty much always a new major release every September/October? Or in other words, either right before or right after Drupal's even numbered minor releases.

Do we know why Chrome 45 has so much usage compared to versions either side?

For worldwide desktop usage, http://gs.statcounter.com/browser-version-market-share/desktop/worldwide..., doesn't register Chrome 45 at all (which is quite a deviation from http://netmarketshare.com/browser-market-share.aspx?qprid=2&qpcustomd=0&...).

I clicked around by region, and found that within all of Asia, it's 2%, and within China, it's 27%.

According to https://en.wikipedia.org/wiki/Google_Chrome#Plugins, support for NPAPI plugins was completely removed in Chrome 45. I don't know if there's any correlation between that and Chinese usage patterns: e.g., incentive for China to update to that version, but not auto-update since then.

I clicked around by region, and found that within all of Asia, it's 2%, and within China, it's 27%.

Chromium and Chrome have same user agent. One of the 360 browser version bundled with Chromium 45 (and few as I've seen used the same based on particular version) and I bet that might be the latest to support XP or something we don't know.

And It's malware-like software you know, once you installed from the internet, by 3rd parties or pre-installed laptop, you can't remove it.

** Note: Average China users can't access Google.com and download Chrome.

** Note: Average China users can't access Google.com and download Chrome.

Right. That explains why people there on Chrome 45 aren't moving off of it. But it doesn't explain why so many people got to Chrome 45 to begin with, rather than us seeing more distributed usage of Chrome 44, Chrome 43, and earlier. I found this comment from a user that says that prior to 45, automatic updates worked through a proxy, but then even that stopped. I'm not immediately finding any corroboration of this, but if that's broadly true rather than a blip for this one user, then maybe that could partially explain it.

The 360 browser has a huge user base. They remove their own ID so that won't identify as 360 in stats anymore.

In China, people not just use official version but use a cleaned version of the software. (The hackers remove the adware and bundled software from the official version) (and might be removed auto-updates also, prevent to install adware again)

360 v8.5 - Chrome 45 (Around 10-2015)
360 v8.6 - I can't find any info, no idea what happens, may be skipped.
360 v8.7 - Chrome 50 (Around 8-2016)
360 v9.0 - Chrome 55 (Around 2-2017)
360 v9.2 - Chrome 55 (Around 8-2017)

V9.2 is the latest release, it still about 1 year behind the Google Official Version.

I've read an article about these browsers before. To upgrade the Chromium isn't an easy job. It's not a skinned browser only but introduced features like IE core inside. (dual engine)

https://www.cvedetails.com/vulnerability-list/vendor_id-1224/product_id-... lists security vulnerabilities in old versions of Chrome, including a recent one for versions prior to 57. If 360 is continually that far behind on which Chrome it uses, how does it manage those security vulnerabilities?

My inclination is that we shouldn't go out of our way to make or keep Drupal working on insecure browsers. But if there's a browser vendor that's providing secure forks of Chrome and that has a huge market share, then we should consider supporting that.

What's next here? The 8.4.0 release notes say:

Additionally, Drupal 8's browser requirements documentation page currently lists incorrect information regarding very outdated browser versions such as Safari 5 and Firefox 5. Clarifications to the browser policy and documentation are underway and we hope to finalize it before 8.4.0-rc1.

We didn't make it before RC1, but can we still finish this up before 8.4.0 (to be released tomorrow)? How close or far are we from consensus?

I think this is still open to discussion. For me the key thing is that we dropped IE 9 and 10 support and that's already documented.

I think we may want to support a larger range of browsers. But it's more important we able to draw a line and to fix the major used browsers first (in the case we need extra time to find a solution for older browsers). Don't let the 5% hurt another 95%.

Fix Major Usages First -> Standard Supported Range -> Case-by-Case patching

It's meaningless if a patch holding for years and then we find that the browsers do not on our support list anymore.

From the issue summary:

Decide if we want a separate issue for discussing Firefox ESR. I don't know how to interpret jQuery's policy with respect to that: do "Current" and "Current-1" apply to that as well, or is Firefox ESR officially not supported by jQuery (since the ESR version is often more than 1 behind the Current Firefox version)? Seems a shame for Drupal, a CMS designed for organizations, to not support a version of Firefox geared towards organizations.

Since I wrote that, jQuery clarified their policy on that:

example ESR versions include Firefox 47, 52 & 60. At any given time there are at most two ESR versions available; jQuery supports both of them.

In other words, they support the "Current" and "Current-1" ESR versions as well.

So, I think it would be great for us to match their list exactly, except for IE, where our minimum is 11 instead of 9. And what I think those minimums should affect are:

• What we accept and fix bugs for.
• What we set our babel build targets to. E.g., in core/package.json.
• What HTML/JS/CSS features we can use without polyfills. E.g., we could start using ShadowDOM once the "Current-1" of Firefox ESR supports it, and then only need to use a polyfill for IE and Edge.

and anything older case by case

I think that's fine, but I think we won't be very successful in keeping those fixes from regressing.

I don't think it's reasonable to ask contributors to manually test on more than just Current.

I agree and I think we should include that in our messaging about what we mean by supported. I.e., that the "Current-1" versions are in practice only really supported to the extent that there are contributors who have that version installed and report bugs and test patches for them. And that at any given time that's a small pool of people, sometimes 0.

In other words, they support the "Current" and "Current-1" ESR versions as well.

Sorry, that's not quite true. The "Current-1" ESR version is only supported for the 12 weeks following a new ESR release.

I think we should also diverge the mobile browser we support from jQuery because they are supporting some pretty old browser versions there (Android 4 had its last release 5 years ago).

If we would support, IE 11, current and current -1 for Chrome, Firefox, Safari, Edge, and Opera, as well as supporting current for Safari mobile, Chrome for iPhone, Chrome for Android, Android browser, UC browser, and Samsung Internet we would get coverage of ~85.71%. This is based on StatCounter data. Getting a significant increase to that percentage would require also a significant increase on the supported browsers list. Besides this, we should add a promise to the browser support policy that we will also support all browsers that have global usage over 1%, even if they aren't part of the list of supported browsers.

It would be ideal if we could stick to a policy on this issue, at least to the extent that we don't extend our support to older browsers after this issue gets resolved. For example, we are planning to remove polyfills that are no longer needed after this issue here #3067216: [meta] Deprecate (in 8.8) and remove (in 9.0) polyfills that are no longer needed, but this couldn't be worked on reliably if we already know that the list of supported browsers might be extended in the near future.

What do we actively test?

When selecting which browser features to use, we should actively ensure that those features are supported by all supported browsers. We have testing infrastructure to only test with the current Chrome version but we could do manual testing occasionally with other versions for browser bugs and inconsistencies.

For above, do we also provide workarounds when the bug is upstream, e.g., in jQuery?

I think it's fine for us to provide workarounds when there are bugs that affect Drupal as a product. However, at least in most cases, we shouldn't provide bug fixes in our codebase to bugs in external dependencies if it doesn't affect the Drupal product.

What we accept and fix bugs for.

By default, we shouldn't accept bug fixes to unsupported browsers since we shouldn't expect committers or other contributors to run those browsers. We could asses the risk case by case basis and make exceptions to this rule when needed.

When do we actively use a new browser feature? For example, Fetch is supported in all current browsers, but not before Firefox 39 or Chrome 42. What becomes the trigger for when we can use it?

In my opinion, we should be able to consider using any given feature after all the supported browsers have either native support or a polyfill.

We updated to jQuery 3 in Drupal 8.4, a little over 2 years ago. As a product manager I support updating our policy to be inline with that. We cannot do anything else at this point anyway given that we don't and don't want to maintain jQuery :)

It would be ideal if we could stick to a policy on this issue, at least to the extent that we don't extend our support to older browsers after this issue gets resolved

I think its entirely sensible that we'll not extend it back again as a general rule. It is hard to predict if any browser would do a very disruptive move, that would require us to support older versions, but I don't expect browsers to do that because it would cause problems for them too likely.

That sounds good to me as well. I don't think jQuery supports it because they want to, it just probably worked out for what they use.

Updated issue summary with the policy proposed in #80.

I think the approach makes sense for us given the current state of browser usage.

I like the statement in #80

Besides this, we should add a promise to the browser support policy that we will also support all browsers that have global usage over 1%, even if they aren't part of the list of supported browsers.

Perhaps we should consider adding that to the policy. I like it because it gives a way for new browsers to be added and listed browsers to be removed without a big discussion. I guess then though we'd have to agree a source of truth for global browser usage.

I'm +1 to the idea of adding the 1% global usage to the policy to give an idea what is the level of usage needed from a browser to be considered supported.

Added support for browsers with > 1% usage based on can I use browser usage table to the proposed policy. Confirmed on Slack that @catch is fine with this as well so I'm keeping this RTBC.

Created change record.

I like what's in the issue summary and change record. Just a couple questions:

• Even though it doesn't have 1% usage, can we still add Firefox ESR to the list? My recommendation would be for us to support the same ESR versions that Mozilla supports: meaning the Current ESR version, and the Current - 1 ESR version for 12 weeks. In other words, currently that would mean supporting both Firefox 60 and 68, but we could drop Firefox 60 after October 23 (the point at which Firefox 68 is 12 weeks old).

• Any browser with > 1% usage based on can I use browser usage table

  That table doesn't list browser usage; it lists browser version usage. So do we mean "any browser version with >1% usage"? Which, for example, might occasionally include the Current - 2 version of Chrome. Or, do we mean "the current version of any browser whose current version usage is >1%"? Or do we mean "the current version of any browser whose combined usage across all versions is >1%"?

• I'd suggest we consider lowering the browser (version?) usage threshold to 0.5%. Looking at the current caniuse table, it wouldn't make a difference, but considering that even Opera is <1%, I think that 1% might be too high a threshold. If that threshold is for browser versions, then lowering the threshold might have the impact of us supporting Chrome's Current-2 or Current-3 for longer, but that might actually be the responsible/courteous thing to do if/when >0.5% of people still use those older versions.

I'd suggest we consider lowering the browser (version?) usage threshold to 0.5%.

Another way of framing that could be 1% of desktop share or 1% of mobile share, since those are approximately 50/50.

Re #95, how about we rephrase part 1 of the issue summary's proposed resolution to:

• Internet Explorer 11
• Excluding Internet Explorer, the Current and Current - 1 versions of desktop browsers with >1% worldwide desktop market share. At present this includes:
  • Google Chrome
  • Firefox
  • Safari
  • Microsoft Edge
  • Opera
• The ESR version(s) of Firefox supported by Mozilla
• The Current version of mobile browsers with >1% worldwide mobile market share. At present this includes:
  • Google Chrome (for both Android and iPhone)
  • Safari mobile
  • Samsung Internet
  • UC browser
  • Opera mobile (including Opera Mini and Opera Touch)
  • Android browser

Note that other than rephrasing and linking the usage to statcounter instead of caniuse, the above also adds Opera mobile to the list, because according to statcounter, it has >1% market share.

when Firefox 72 comes out, do we support Firefox 72, 71, and 68, or only Firefox 72 and 68?

The ESR and non-ESR audiences are different, so #96 is written to keep them separate, which would mean we'd support 72 (Current), 71 (Current-1), and 68 (ESR). I'm open to changes to #96 though if there's a good reason to do something different than that.

I think the CR could use a little a further work to help explain to users what this means:

Current version and current version -1 of Google Chrome, Firefox, Safari, Microsoft Edge, and Opera

That could use a little context as to what that means, because I think modern browser users have no idea what this means. Does this mean (as of right now today) only Chrome 75 and 76, meaning that if you have Chrome 74 (released in April 2019), Drupal's not supported? Are there references or TLDR explanations we can link the user?

Any browser with > 1% usage based on can I use browser usage table

Is this an OR or an AND with the first bullet? Chrome 74 has dipped to 0.5%, but there might have been a point after 76's release that it was over 1%.

Do mobile browsers also get the "and -1" or not?

Overall this seems fine to me. We need a release note for the 8.8.0 release notes, and we'll need to also update handbook docs prior to marking this fixed.

This is also a D9 readiness issue since it will affect what polyfills we deprecate for removal in 9.0.0.

statcounter instead of caniuse

Everywhere and ES6 in CORE used broswerlist
https://git.drupalcode.org/project/drupal/blob/8.8.x/core/package.json#L51

If we can figure out the query and put online, everyone doesn't need to read thousands word :p
https://browserl.ist

Opera Mobile & Opera Mini are two very different product. #96 counted by broswer, not versions

- When to drop the older supports? At release date or beginning of a new branch?
- Should we only look at last month data? Or 3 months average?

To me, the Compatibility list is equal to well-tested before releases, not only accept patches. I think the doc page should indicate that the CORE provided limited supports for all IEs and Opera mini. This is a real fact, the community has no momentum to work out a patch or review that.

https://browserl.ist/ says that "Data provided by caniuse-db". Meanwhile, https://caniuse.com/ says "Usage share statistics by StatCounter GlobalStats", so in theory it's all the same data. However, https://caniuse.com/usage-table says:

Browser usage table, based on data from StatCounter GlobalStats
Information for mobile versions is extrapolated from other sources.

Um, anyone know what those other sources are?

One example where there's a discrepancy is for Android Browser. https://browserl.ist lists Android Browser 67 at 0%. Right, but does a v67 of Android Browser even exist? Meanwhile, https://gs.statcounter.com/browser-market-share/mobile-tablet/worldwide/ lists "Android" at 1.32%, and if you download the CSV from https://gs.statcounter.com/browser-version-market-share, all of that is listed under "Android 0".

Additionally, https://browserl.ist lists Opera Mobile 46 at 0.01%. Why doesn't it list more recent versions of Opera Mobile? Meanwhile, it lists Opera Mini at 1.42%, but that's aggregated for all Opera Mini versions. Is there a reason they chose to single out Opera Mini as the only one to aggregate? Something special about a mobile proxy browser that makes version less relevant?

So I guess the questions for us are:

• Would we rather base our policy on statcounter directly, or on browserlist's/caniuse's combination of statcounter and "other sources"?
• Should we include Android Browser in our supported browser list if statcounter claims that there's >1% usage of it, presumably across multiple EOL Android versions but all lumped under "Android 0"?
• Given browserlist's listings for Opera Mobile and Opera Mini, should Drupal support either or both?

Statcounter website showing different result than that their downable CSV.

For example the Chrome for Android, that's around 30% more on their website.

Mobile & Tablet Browser usage < Mobile only... It's odd

Android Browser 67 at 0%. Right, but does a v67 of Android Browser even exist?

I guess Android Browser 67 is the latest version still release with Android Browser, afterward that is Chrome for Android. That's happening around Android 4.4

Meanwhile, https://gs.statcounter.com/browser-market-share/mobile-tablet/worldwide/ lists "Android" at 1.32%, and if you download the CSV from https://gs.statcounter.com/browser-version-market-share, all of that is listed under "Android 0".

Android 0 on CSV for August is 0.73% only. Even not the average, the latest 10 months are below 1%.

Opera Mobile 46 at 0.01%. Why doesn't it list more recent versions of Opera Mobile?

I think this case is similar to the Android Browser. Opera keeps re-branding and multiple releases now. some only for Android or iOS. And PlayStation devices also using Opera.

Opera Mobile ( the Chromium-based / Opera Touch ) is showing Chrome user-agent instead.

BTW, the https://browserl.ist is using cached 31 July 2019 data.

Supporting Firefox ESR seems like a good idea since supporting it has strategic importance to Drupal. It's also supported by browserlist meaning that it will be easy to add it to our babel configuration.

We should open follow-ups to discuss adding the percentage rule to the policy, and to update our babel configuration with the supported browsers from the new policy.

+1 for #102. Thanks for doing that in #104.

By default, Drupal core is not accepting bug fixes to unsupported browsers since we shouldn't expect committers or other contributors to run unsupported browsers.

+1 to this reasoning.

Current release of Safari mobile, Chrome for iPhone, Chrome for Android, Android browser, UC browser, and Samsung Internet

Per #100 / #101, what is the "Current" release of Android Browser? Is that still a thing, or does Android Browser only have legacy, non-current, versions at this point? If the latter, then should we remove it from this list and discuss whether to add it in #3080068: [policy, no patch] Define usage heuristics for browser support? If there is such a thing as a current release of Android Browser, then never mind and sorry for my ignorance.

Good catch @effulgentsia! Android Browser was replaced with Chrome for Android some years ago. It also falls way below the > 1% threshold. Support for Android 4.4 ended in October 2017 which was the latest release to ship with Android Browser. Therefore we definitely shouldn't support it and expect contributors to be running that browser.

This looks very close to rtbc - I think before we do that we need to account for the needs release note tag.

Current, and previous releases of Google Chrome, Firefox, Safari, Microsoft Edge, and Opera

This has some grammar ambiguity so could be reworded for clarity. Currently, "previous releases" could be misconstrued to mean more than 1 previous release.

Do mobile browsers also get the "and -1" or not?

According to the proposed resolution, no they do not. Do we want to add language for why not? Are we assuming that people are better at keeping their mobile apps up to date than they are with their desktop browsers? Or is there other rationale for us not supporting the -1 version on mobile?

Are we assuming that people are better at keeping their mobile apps up to date than they are with their desktop browsers? Or is there other rationale for us not supporting the -1 version on mobile?

Mobile browsers are kept more up to date than desktop browsers. For example, the previous Chrome release is still used by over 7% which is a lot in comparison to the previous version of Safari mobile which is only used by ~1%.

I created some queries using browserlist service to demonstrate this. If we support the current version of mobile browsers, around 87% of the traffic would use supported browsers. If we also supported 1 previous release of mobile browsers, this would increase to 88.5%. However, if we only supported current version of both, mobile and desktop browsers, this would go down to 67% of traffic supported.

I'm wondering if we should drop support for Chrome for iPhone since it doesn't seem like we have any data to back that it would be useful. Also, since it isn't supported by browserlist, we wouldn't be able to add it to our automated tooling.

I'm not sure what should we do about Opera Mobile since according to browserlist it's used by 0.01% of traffic. Is that data incorrect or is there some other reason why we should be supporting it?

In my own development stack, I always included "last 2 iOS major versions" (which is iOS 12 current & iOS 11, not 12.x & 12.x)

Even though iOS Safari has less than 1% in the collected data but the Apple doc showed 7% iOS 11 system usages. You can't use any another engine in iOS.
https://browserl.ist/?q=last+2+iOS+major+versions

*my own strategy is only to support CSS / JS syntax, not new features. This is different than Drupal so far.

I'm wondering if we should drop support for Chrome for iPhone since it doesn't seem like we have any data to back that it would be useful.

I have an iPhone. I went into my App Store, to the Top Charts, to see the listing of All Apps by popularity. I don't see where it says how many downloads/installs each one has, but they are ranked. They're separated by Free Apps and Paid Apps. Among the Free Apps, Google Chrome is #25. For comparison, Uber is #20, Netflix is #21, and Twitter is #26. I don't know if this listing is Global or per-region. If it's per-region, then it's probably showing me US, since that's where I am. I think that #25 of all iOS apps makes it sufficiently "useful" to support.

Also, since it isn't supported by browserlist, we wouldn't be able to add it to our automated tooling.

That's a shame and definitely worth considering. I don't know what the best answer for this is. Maybe, since all iOS browsers are required by Apple to use WebKit we could just assume that our automated testing of iOS Safari is enough to give us reasonable confidence that iOS Chrome works too? However, if someone does find a Drupal bug on iOS Chrome that doesn't exist on iOS Safari, then I think it's reasonable for us to accept that bug report and a fix to it. However, if it's an issue that stems from problems with automated tooling that is unaware of iOS Chrome quirks, that might prove difficult.

I'm not sure what should we do about Opera Mobile since according to browserlist it's used by 0.01% of traffic. Is that data incorrect or is there some other reason why we should be supporting it?

Opera keeps rebranding their products. Does Opera Mobile exist anymore? Or is the current mobile product line now just Opera Mini, Opera for Android, and Opera Touch? I'd be fine with punting decisions on Opera for Android and Opera Touch to #3080068: [policy, no patch] Define usage heuristics for browser support.

Current release of ... Opera Mini ...

Opera Mini used to exist for iOS but no longer does. I wonder if we should explicitly say that we only support it for Android or if that's implied (as it is for Samsung Internet).

If https://dev.opera.com/articles/browsers-modes-engines/ is still accurate (I don't know if it is), then Opera Mini on Android has two different modes: one using Presto and one using WebView. The default one is Presto. Should we explicitly say whether or not we support both?

I'm currently concerned about whether Drupal actually works on Opera Mini with the Presto engine. https://dev.opera.com/articles/making-sites-work-opera-mini/ and https://dev.opera.com/articles/opera-mini-and-javascript/ explain things that need to be considered for that. #2119299: Make sure Drupal 10 works with mobile proxy browsers is still an open issue. However, even if Drupal has bugs on Opera Mini, I certainly think we should accept bug reports and fixes for them, so from that standpoint, I agree with it being in our policy. But I wonder if we should put some caveat into our policy that lets people know about the current state of things.

In my own development stack, I always included "last 2 iOS major versions" (which is iOS 12 current & iOS 11, not 12.x & 12.x)

As of yesterday/today, it's now 12 and 13. Which brings up a good point. I agree with #110 that we should add Current-1 for iOS Safari. Because Apple still supports it. And because Apple still supports hardware that is unable to upgrade to the latest iOS. For example, iPhone 6 cannot upgrade to iOS 13. That means a different policy for iOS Safari than for the other mobile browsers, but I think it's justified.

Current, and 1 previous release

I think this is ambiguous. For example, when Safari 13.1 comes out, will the previous release be 12.1 or 13.0? I'm pretty sure the intention is the former (the previous major version), so let's clarify that in the policy wording. Perhaps something like "The latest release for each of the last two major versions (the current major version and the 1 prior major version)". A potential downside with this suggestion though is whether or not people who will be reading this policy know what "major versions" are for Chrome and Firefox, so maybe this wording could still use refinement to clarify / educate people on that.

The change record doesn't say the same as the issue summary

• Firefox ESR is in the IS, but isn't mentioned in the CR.
• The CR mentions Android Browser, but the IS doesn't.
• The CR has the >1% clause, but the IS doesn't.

If a version of Chrome/Firefox/Edge/Opera/Safari is older than current -1, but has >1%, do we support it?

+1 for Firefox ESR. Anecdotally, I've heard from workplace accessibility assessors that some organizations install Firefox ESR specifically because a screen reader user wants it. It goes something like this:

1. Organization employs a visually impaired user, who wants a screen reader.
2. Organization says: "OMG, JAWS is so expensive! Will NVDA do? That's free."
3. Employee and/or the workplace accessibility assessor says: "Sure, but NVDA works best with Firefox."
4. Organization installs Firefox ESR and NVDA.

I totally want to support that.

If a version of Chrome/Firefox/Edge/Opera/Safari is older than current -1, but has >1%, do we support it?

This should be discussed in #3080068: [policy, no patch] Define usage heuristics for browser support.

I'm currently concerned about whether Drupal actually works on Opera Mini with the Presto engine.

I tried to install Opera Mini for Android using emulator but I simply couldn't find package that would be compatible with any of the OS versions or platforms that I had available in the emulator. I tested Drupal with Opera Mini Symbian using these instructions and I could confirm that for the most part, everything was functional. As far as I could tell, all of them were generic no-js bugs that we should probably fix. I'm not sure how we can commit to supporting the Android version if there is no way to run it 🤷‍♂️

Maybe, since all iOS browsers are required by Apple to use WebKit we could just assume that our automated testing of iOS Safari is enough to give us reasonable confidence that iOS Chrome works too? However, if someone does find a Drupal bug on iOS Chrome that doesn't exist on iOS Safari, then I think it's reasonable for us to accept that bug report and a fix to it. However, if it's an issue that stems from problems with automated tooling that is unaware of iOS Chrome quirks, that might prove difficult.

It doesn't seem reasonable to commit to supporting this at the moment given that our tooling doesn't support this. Maybe we should open issue to browserlist to see if this is something that could be solved?

Many quirks can't catch by automated tooling. This isn't a good reason to drop it. Even manual testing on a real iPhone & iOS Simulator, you can find differences sometimes.

On the iOS platform browsers, mainly that's viewport (, scroll action is a funny thing) and clicking behavior differences. These things are the weakest part of automated tooling.

After realizing how difficult it’s to set up Opera Mini without having the hardware to run it, I realized that we might want to take that into consideration. For example, there’s no way to do testing with Samsung Internet without buying either buying the hardware, or a commercial service. Should we only include browsers in the list that we can test reasonably? Maybe we should try to apply for a BrowserStack Open Source license. This would make testing different browsers much easier, but I assume we could access to only a limited number of people.

Should we open a follow-up for discussing when are we requiring browser compatibility tests on issues and on which browsers? Then we could rescope this issue to discussing which browsers we accept bug fixes for.

I gave some more consideration to Chrome in iOS. Technically specifying the iOS version should be enough to get Babel coverage for Chrome in iOS since it's running on the same engine as Safari. If we think #111 provides enough justification, we should be able to provide support for it.

Additionally bug reports will be accepted for UC browser and Opera Mini, but they will not yet be actively tested on due to lack of readily available testing tools

In my opinion this should be a separate discussion which I proposed to move to a follow-up in #115. In my opinion, these browsers should be marked as supported just like all the other browsers. We don't have policy to require testing issues on certain browsers. If we say we don't actively test on UC Browser and Opera Mini, that gives an impression that the other browsers are actively being used for testing which isn't the case.

Also, in my opinion, the reasoning we are giving here doesn't justify this. There are other browsers that are difficult to run as well. For example, testing iOS Safari requires an iPhone or a Mac.

So I think we need to say something like "Volunteer contributors test manually test important changes in supported browser to the extent that the contributors are able." We need to be honest about what the policy means, and we can improve it in the future when we have more scalable ways to do these browser testing.

Based on info about SauceLabs etc. it's going to remain the case for now that it's much easier to find some contributor at a sprint with an Apple phone than someone set up to test those specific browsers. But let's set an honest policy now, define what means, and show how it can also be improved later as new tools become available to us.

How about this:

1. Update https://www.drupal.org/docs/8/system-requirements/browser-requirements to:
   • The latest release for each of the last two major versions of Google Chrome, Firefox, Safari, Microsoft Edge, Opera and Safari mobile
   • The latest release of the latest major version of Chrome for Android, Chrome for iOS, UC Browser [see note below], Opera Mini [see note below] and Samsung Internet [see note below]
   • Firefox ESR
   • Internet Explorer 11
2. Clarify what our browser support means.
   • Drupal accepts bug reports for supported browsers.
   • Contributors manually test significant changes in multiple browsers to watch for regressions, but this is somewhat based on the contributors available and the particular issue. We do not yet have full automated browser testing for our supported browsers.
   • Note: UC Browser, Opera Mini, and Samsung are not always available for our community of contributors to test before a commit so there may be regressions, but we still accept bug reports.
3. By default, Drupal core does not accept bug fixes to unsupported browsers. Committers and the security team will asses the risk case by case basis and make exceptions to this rule when needed.
4. Drupal can start using any given browser feature once all the supported browsers have either native support or a polyfill. Polyfills can be removed after all supported browser support given feature natively.

Edit: Simplified some wording

We should open a follow-up for #115.

Contributors manually test significant changes in multiple browsers to watch for regressions, but this is somewhat based on the contributors available and the particular issue. We do not yet have full automated browser testing for our supported browsers.

+1 to adding this clarification. Maybe we can remove this after we have more confidence in our capability to ensure cross-browser compatibility.

Note: UC Browser, Opera Mini, and Samsung are not always available for our community of contributors to test before a commit so there may be regressions, but we still accept bug reports.

I'm not in favor of adding this since I believe users would find this very confusing. We already say that browser support is provided with best efforts which should be enough.

Here's the followup for #115: #3083662: Define expectations for testing on supporting browsers and how to achieve them.

Fixed formatting in the IS for the list under "Clarify what our browser support means.".

Reformatting the browser lists into sublists for easier scanning.

The IS looks good to me now. #126 and #127 only changed formatting, not wording. I'm tempted to re-RTBC this, but leaving that to @xjm for her to make sure the changes in #124 adequately reflect her prior feedback.

Moved Firefox ESR and IE into sub-bullets of the 2nd item, for symmetry.

Nitpicky wordsmithing.

I think this looks good! I fixed a typo.

Regarding:

Drupal can start using any given browser feature once all the supported browsers have either native support or a polyfill. Polyfills can be removed after all supported browsers support the given feature natively.

I'd like to change that to something like:

Drupal can start using any given browser feature once all the supported browsers have either native support or a polyfill. In each major release, polyfills that are no longer needed (because all supported browsers have added the feature natively) will be removed.

No big deal though.

Extra info.

I'm looking forward to seeing the CORE to provide extra information to the developers in a proper way. It helps to maintain the Lean Core or helps developers to expand their support.
#2818655: Introduce `Support:` syntax tagging Browser Hacks in source code

+1 to adding #131 and to RTBC.

For whoever updates the handbook page on this, I think the information would be best presented as a table, e.g. something like

Desktop browsers

(Edited to make the example actually make sense.)

My 2c, I think we should change the language slightly from

The latest release of the latest major version of:

to

The latest vendor supported release of the latest major version of:

So that if any of those browsers go EOL during the 9 cycle we can drop them

OK, we have signoff on this policy from @xjm, @catch, @Gábor Hojtsy, @webchick, @larowlan, @alexpott, and @effulgentsia.

SHIP IT! ⛵️Who wants to do the handbook updates?

Handbook page updated: https://www.drupal.org/node/2779179/revisions/view/11403843/11582848 — see https://www.drupal.org/docs/8/system-requirements/browser-requirements

Thank you for updating the handbook page @Wim Leers and thanks all for the feedback on the creation of this policy. I opened #3084843: Update browserslist browsers as a follow-up.

I think we should mention this. :)

• Closed #1030090: Document our browser support list as outdated.
• Left a comment at #2119299-15: Make sure Drupal 10 works with mobile proxy browsers to propose to close that issue too since I think this issue already addressed that.

Updating the RN a bit.