Uploaded image for project: 'Moodle'
  1. Moodle
  2. MDL-55750

Update supported browsers list for 3.2 release

    Details

    • Type: Improvement
    • Status: Closed
    • Priority: Blocker
    • Resolution: Fixed
    • Affects Version/s: 3.2
    • Fix Version/s: 3.2
    • Component/s: Policy

      Description

      This issue evolved over time and eventually we decided to change terminology to adapt to the practical reality of browser support in Moodle today:

      User guidance (will be in release notes and so on)

      Moodle is compatible with any standards compliant web browser. We regularly test Moodle with the following browsers:

      Desktop:

      • Chrome
      • Firefox
      • Safari
      • Edge
      • Internet Explorer

      Mobile:

      • MobileSafari
      • Google Chrome

      For the best experience and optimum security, we recommend that you keep your browser up to date. https://whatbrowser.org

      Note: Legacy browsers with known compatibility issues with Moodle 3.2:

      • Internet Explorer 10 and below
      • Safari 7 and below

      Developer guidance:

      Developers are encouraged to embrace modern web technologies when a feature has been implemented by all major vendors (Chrome/Firefox/Edge/Safari). We encourage our users to run on up to date browsers, developers should focus the bulk of their attention on supporting these users when implementing new functionality.

      Questions to ask, when deciding can I use 'feature-x'?

      • What is the impact of this feature not being available?
        • If it breaks the site, you must ensure it is available in firefox/chrome releases over the last 1y and Safari/IE releases not mentioned in our compatibility issues
        • If it's just 'nice to have' cosmetic issue you do not need to be strict
      • Is it supported by all major vendors on all platforms?
        • If not: You can't use this feature yet

      Original description:
      The browser version landscape has changed and we need to update our supported browser policy to reflect this.

      Microsoft have moved to a continuous update model with IE11 / IE Edge and no longer support older versions on any version of windows. We should not either.

      We currently list very old versions of the other browsers, but do not test on them (automated tests included).

      We have technical reasons for not supporting older browser versions, especially for 3.2 which introduces a new theme - using bootstrap 4 which does not support old browsers. 3.2 also immediately follows an LTS release so it is a good time to be aggressive.

      Review the current browser statistics page and come up with a new base line for the list of supported browsers.

      Desktop

      Internet Explorer - Edge + 11
      Safari - 8+
      Firefox - 44+
      Chrome - 44+

      Mobile

      Chrome - 51+
      IOS Safari - 8+

      For reference here is the list of supported browsers for Moodle 3.1

      Google Chrome 30.0 Latest
      Mozilla Firefox 25.0 Latest
      Apple Safari 6 Latest
      Microsoft Internet Explorer 9 Latest Version 10 is required for drag-and-drop upload of content from outside the browser into Moodle

        Gliffy Diagrams

          Attachments

            Issue Links

              Activity

              Hide
              damyon Damyon Wiese added a comment -

              Deciding this would also let us remove the "CSS chunker" from Moodle which is a giant hack around the problem that we have too much CSS in Moodle.

              Show
              damyon Damyon Wiese added a comment - Deciding this would also let us remove the "CSS chunker" from Moodle which is a giant hack around the problem that we have too much CSS in Moodle.
              Hide
              damyon Damyon Wiese added a comment -

              Note that we don't HAVE to be so aggressive with IE - bootstrap still supports IE9+ (for the time being).

              BUT - older versions are not supported by Microsoft themselves.

              https://www.microsoft.com/en-au/WindowsForBusiness/End-of-IE-support

              Show
              damyon Damyon Wiese added a comment - Note that we don't HAVE to be so aggressive with IE - bootstrap still supports IE9+ (for the time being). BUT - older versions are not supported by Microsoft themselves. https://www.microsoft.com/en-au/WindowsForBusiness/End-of-IE-support
              Hide
              tmuras Tomasz Muras added a comment -

              I agree with "immediately follows an LTS release so it is a good time to be aggressive.". Now is a good time for the decision like this.

              Show
              tmuras Tomasz Muras added a comment - I agree with "immediately follows an LTS release so it is a good time to be aggressive.". Now is a good time for the decision like this.
              Hide
              mudrd8mz David Mudrák added a comment -

              Just note that even if the browser producers themselves adopted the continuous update model and are releasing new versions more often these days (together with auto-updating mechanisms built into the browsers themselves), it does not mean that all the software distributors follow it same quickly. Linux distributions have their own workflows of the software staging and it can take time before a released browser version is marked as "stable" within the particular distro.

              I don't disagree with a need to update the policy. I just feel there might be a bit more factual reasoning put for the "latest and one previous version" decision/

              Some schools / institutions may be conservative and upgrade their software less often. I am aware this would then include Moodle itself so it is not a big issue. But it should be clear that an analysis of actual browser versions usage (e.g. from https://www.netmarketshare.com/ or other) was taken into account before deciding this. Also, I live in impression we sort of specify actual browser features we depend on, rather than particular versions. Am I wrong?

              In general, let us require as recent versions as we need, but not more recent just because we can.

              Show
              mudrd8mz David Mudrák added a comment - Just note that even if the browser producers themselves adopted the continuous update model and are releasing new versions more often these days (together with auto-updating mechanisms built into the browsers themselves), it does not mean that all the software distributors follow it same quickly. Linux distributions have their own workflows of the software staging and it can take time before a released browser version is marked as "stable" within the particular distro. I don't disagree with a need to update the policy. I just feel there might be a bit more factual reasoning put for the "latest and one previous version" decision/ Some schools / institutions may be conservative and upgrade their software less often. I am aware this would then include Moodle itself so it is not a big issue. But it should be clear that an analysis of actual browser versions usage (e.g. from https://www.netmarketshare.com/ or other) was taken into account before deciding this. Also, I live in impression we sort of specify actual browser features we depend on, rather than particular versions. Am I wrong? In general, let us require as recent versions as we need, but not more recent just because we can.
              Hide
              sbourget Stephen Bourget added a comment -

              How would you handle institutions that use browser extended support releases like Firefox ESR?
              (https://www.mozilla.org/en-US/firefox/organizations/faq/)
              Note the current ESR build is 45.3 and most likely will still be 45.X by the time Moodle 3.2 is released.

              Show
              sbourget Stephen Bourget added a comment - How would you handle institutions that use browser extended support releases like Firefox ESR? ( https://www.mozilla.org/en-US/firefox/organizations/faq/ ) Note the current ESR build is 45.3 and most likely will still be 45.X by the time Moodle 3.2 is released.
              Hide
              mudrd8mz David Mudrák added a comment -

              handle institutions that use browser extended support releases like Firefox ESR?

              I understood it is assumed that if the institution use such release for browsers, they will prefer to use LTS for Moodle, too. So the policy might include that LTS Moodle should also support LTS browsers.

              Show
              mudrd8mz David Mudrák added a comment - handle institutions that use browser extended support releases like Firefox ESR? I understood it is assumed that if the institution use such release for browsers, they will prefer to use LTS for Moodle, too. So the policy might include that LTS Moodle should also support LTS browsers.
              Hide
              sbourget Stephen Bourget added a comment -

              I understood it is assumed that if the institution use such release for browsers, they will prefer to use LTS for Moodle, too. So the policy might include that LTS Moodle should also support LTS browsers.
              

              I disagree, we run the ESR build of Firefox so we can have a stable browser platform for the school year (We have about 2000 devices split across 6 schools) all of which supporting students ages 6-18.
              We upgrade Moodle each summer to the latest stable (meaning next summer we will upgrade to 3.3) at that time we upgrade the browsers to the latest ESR release. (It's less work to upgrade a Moodle install than it is to upgrade 2000 school owned devices)

              The firefox ESR build is only supported by Mozilla for 1 year, which is the same as the standard support cycle for Moodle.

              Show
              sbourget Stephen Bourget added a comment - I understood it is assumed that if the institution use such release for browsers, they will prefer to use LTS for Moodle, too. So the policy might include that LTS Moodle should also support LTS browsers. I disagree, we run the ESR build of Firefox so we can have a stable browser platform for the school year (We have about 2000 devices split across 6 schools) all of which supporting students ages 6-18. We upgrade Moodle each summer to the latest stable (meaning next summer we will upgrade to 3.3) at that time we upgrade the browsers to the latest ESR release. (It's less work to upgrade a Moodle install than it is to upgrade 2000 school owned devices) The firefox ESR build is only supported by Mozilla for 1 year, which is the same as the standard support cycle for Moodle.
              Hide
              mudrd8mz David Mudrák added a comment -

              It's less work to upgrade a Moodle install than it is to upgrade 2000 school owned devices

              That's a good point. Thanks Stephen.

              Show
              mudrd8mz David Mudrák added a comment - It's less work to upgrade a Moodle install than it is to upgrade 2000 school owned devices That's a good point. Thanks Stephen.
              Hide
              joeyandres Joey Andres added a comment -

              We should take http://caniuse.com/usage-table into account. That being said glad we are using ie11 as baseline for ie.

              Show
              joeyandres Joey Andres added a comment - We should take http://caniuse.com/usage-table into account. That being said glad we are using ie11 as baseline for ie.
              Hide
              danmarsden Dan Marsden added a comment -

              Here at Catalyst we think this is probably a good idea - although we have clients running older browser versions on internally managed devices and we'll have to find ways of managing those sites - either by running older versions of Moodle (maybe LTS) - and/or spending more time testing etc. It would be nice if the policy included some scope for community supplied patches to resolve major problems with older browsers even though "official" support is not provided.

              Also - crazy idea... moving forward I wonder if we should be keeping track of browser type within Moodle logs, and then provide a tool that shows some browser stats to the admin to give them an idea on the impact of upgrading to a newer release? - We already do this with 3rd party plugins like piwik/GA but it would be nice for the environment check page to say 20% of the users on your site use a browser not supported by the next moodle release - you may want to stay on the current release until this drops?

              Show
              danmarsden Dan Marsden added a comment - Here at Catalyst we think this is probably a good idea - although we have clients running older browser versions on internally managed devices and we'll have to find ways of managing those sites - either by running older versions of Moodle (maybe LTS) - and/or spending more time testing etc. It would be nice if the policy included some scope for community supplied patches to resolve major problems with older browsers even though "official" support is not provided. Also - crazy idea... moving forward I wonder if we should be keeping track of browser type within Moodle logs, and then provide a tool that shows some browser stats to the admin to give them an idea on the impact of upgrading to a newer release? - We already do this with 3rd party plugins like piwik/GA but it would be nice for the environment check page to say 20% of the users on your site use a browser not supported by the next moodle release - you may want to stay on the current release until this drops?
              Hide
              joeyandres Joey Andres added a comment -

              I think you have to factor in the fact that not most organization do not upgrade to the current latest one till a year or two later. This is to be conservative and not risk incompatibilities.

              Concerning the impact of upgrade with respect to browser version, that could easily be field in Jira/tracker. I don't work with Moodle but I'm sure their operational folks won't mind adding a field, if its not there.

              Show
              joeyandres Joey Andres added a comment - I think you have to factor in the fact that not most organization do not upgrade to the current latest one till a year or two later. This is to be conservative and not risk incompatibilities. Concerning the impact of upgrade with respect to browser version, that could easily be field in Jira/tracker. I don't work with Moodle but I'm sure their operational folks won't mind adding a field, if its not there.
              Hide
              sbourget Stephen Bourget added a comment -

              Does HQ have any browser usage statistics from either Moodle.org or learn.moodle.net? I'd be curious to see what those user bases look like. (The browser stats from learn moodle could give some insight into what teachers are using.)

              My only real concern with the latest version and the previous version of browser requirement is that it leaves a lot of inconsistency in browser support. A two year old version of safari would be supported (Safari 8 was released in 2014), but a build of chrome / firefox that was installed 4 months ago would not be supported since they release every 6 weeks.
              (It seems odd that the version of firefox or chrome used to write a Moodle feature at the beginning of a development cycle would not be supported when that version of Moodle is released, since Mozilla / Google would have had 4 releases during that single Moodle development cycle)

              Show
              sbourget Stephen Bourget added a comment - Does HQ have any browser usage statistics from either Moodle.org or learn.moodle.net? I'd be curious to see what those user bases look like. (The browser stats from learn moodle could give some insight into what teachers are using.) My only real concern with the latest version and the previous version of browser requirement is that it leaves a lot of inconsistency in browser support. A two year old version of safari would be supported (Safari 8 was released in 2014), but a build of chrome / firefox that was installed 4 months ago would not be supported since they release every 6 weeks. (It seems odd that the version of firefox or chrome used to write a Moodle feature at the beginning of a development cycle would not be supported when that version of Moodle is released, since Mozilla / Google would have had 4 releases during that single Moodle development cycle)
              Hide
              danmarsden Dan Marsden added a comment -

              @stephen - you might be confusing "works" and "supported" ... I'm guessing the main driver for this relates to the testing process at time of actual release.

              Show
              danmarsden Dan Marsden added a comment - @stephen - you might be confusing "works" and "supported" ... I'm guessing the main driver for this relates to the testing process at time of actual release.
              Hide
              damyon Damyon Wiese added a comment -

              Regarding "supported" - we should include some clear text on what this means.

              IMO it should mean this:

              • Automated tests are run on this browser version and are known to be passing 100% - or the failures should be known to be caused by a bug in the automation driver for this browser and not by the browser/moodle
              • When looking to use a particular browser feature we should provide a fallback if the feature does not exist on all supported browsers
              • When adding a workaround for a bug in a browser we should remove the work-around when the bug no longer exists in any of the supported browsers
              Show
              damyon Damyon Wiese added a comment - Regarding "supported" - we should include some clear text on what this means. IMO it should mean this: Automated tests are run on this browser version and are known to be passing 100% - or the failures should be known to be caused by a bug in the automation driver for this browser and not by the browser/moodle When looking to use a particular browser feature we should provide a fallback if the feature does not exist on all supported browsers When adding a workaround for a bug in a browser we should remove the work-around when the bug no longer exists in any of the supported browsers
              Hide
              danmarsden Dan Marsden added a comment -

              I'm not convinced on your 3rd point in that list..... maybe add a timeframe around that - remove the bug when it no longer exists in the last X supported browers - or not supported in any Moodle LTS versions?

              Show
              danmarsden Dan Marsden added a comment - I'm not convinced on your 3rd point in that list..... maybe add a timeframe around that - remove the bug when it no longer exists in the last X supported browers - or not supported in any Moodle LTS versions?
              Hide
              damyon Damyon Wiese added a comment -

              Re: removing workarounds - the important thing is to have a defined timeframe to remove old code.

              Show
              damyon Damyon Wiese added a comment - Re: removing workarounds - the important thing is to have a defined timeframe to remove old code.
              Hide
              rajeshtaneja Rajesh Taneja added a comment - - edited

              From testing point of view, it will be nice to increase min version support, especially for ie and FF. Reason being:

              1. Specific versions of Firefox works with specific versions of selenium.
              2. memory leaks in IE driver and no further work is being done.

              In general, I don't see normal user being effected as most of the browsers update automatically and from the link Joey Andres shared it is clear that most of the users are using latest or last released versions. Only place this is going to affect/hit hard is institutes which are stuck with specific version of browsers, either because of cirtix (ie case) or FF ESR.

              It would be nice, if we can have a forum post and try ask community to give there preference via social media to ensure we don't lose trust of community. Probably a good Marketing task to get numbers.

              Personally, I think it would be ideal, if we can support current + last browser version.

              Desktop browsers
              1. Internet Explorer (current version status from Wikipedia)
              2. Firefox (current version status from Wikipedia)
              3. Chrome (current version status from Wikipedia)
              4. Opera (current version status from Wikipedia)
              5. Safari (current version status from Wikipedia)
              6. Edge (current version status from Wikipedia)
              Mobile browsers
              1. Android browser - 51 and 52
              2. Mobile Safari - 8 and 9
              Show
              rajeshtaneja Rajesh Taneja added a comment - - edited From testing point of view, it will be nice to increase min version support, especially for ie and FF. Reason being: Specific versions of Firefox works with specific versions of selenium. memory leaks in IE driver and no further work is being done. In general, I don't see normal user being effected as most of the browsers update automatically and from the link Joey Andres shared it is clear that most of the users are using latest or last released versions. Only place this is going to affect/hit hard is institutes which are stuck with specific version of browsers, either because of cirtix (ie case) or FF ESR. It would be nice, if we can have a forum post and try ask community to give there preference via social media to ensure we don't lose trust of community. Probably a good Marketing task to get numbers. Personally, I think it would be ideal, if we can support current + last browser version. Desktop browsers Internet Explorer ( current version status from Wikipedia) Firefox ( current version status from Wikipedia) Chrome ( current version status from Wikipedia) Opera ( current version status from Wikipedia) Safari ( current version status from Wikipedia) Edge ( current version status from Wikipedia) Mobile browsers Android browser - 51 and 52 Mobile Safari - 8 and 9
              Hide
              mudrd8mz David Mudrák added a comment -

              I think it will help communicating this policy if we name it correctlythen : "Moodle is tested on the last two versions of each major browser" without using the word "supported". From reality, I know we do not close doors from patches that fix experienced issues with older browsers as long as the patch is reasonable.

              Show
              mudrd8mz David Mudrák added a comment - I think it will help communicating this policy if we name it correctlythen : "Moodle is tested on the last two versions of each major browser" without using the word "supported". From reality, I know we do not close doors from patches that fix experienced issues with older browsers as long as the patch is reasonable.
              Hide
              poltawski Dan Poltawski added a comment -

              "Moodle is tested on the last two versions of each major browser" without using the word "supported"

              Yeah, absolutely agree with this sentiment (it matches the reality and movement of browser technology). That terminology also helps with Moodle partners and other organisations who have to fulfil particularly customer requirements for browser support. When I was 'selling' Moodle, that the official supported browser list didn't match with one customer's requirement didn't bother me from a technical point of view (because the reality was that it would work fine) but it was a major barrier to convince the customer about it. It's actually better if our terminology closer matches the practical reality.

              Show
              poltawski Dan Poltawski added a comment - "Moodle is tested on the last two versions of each major browser" without using the word "supported" Yeah, absolutely agree with this sentiment (it matches the reality and movement of browser technology). That terminology also helps with Moodle partners and other organisations who have to fulfil particularly customer requirements for browser support. When I was 'selling' Moodle, that the official supported browser list didn't match with one customer's requirement didn't bother me from a technical point of view (because the reality was that it would work fine) but it was a major barrier to convince the customer about it. It's actually better if our terminology closer matches the practical reality.
              Hide
              damyon Damyon Wiese added a comment -

              But should we be blocked from using new browser features that are supported in the last two versions of all major browsers ?

              Show
              damyon Damyon Wiese added a comment - But should we be blocked from using new browser features that are supported in the last two versions of all major browsers ?
              Hide
              danmarsden Dan Marsden added a comment -

              no - but it would be nice if a feature like that didn't completely break Moodle for a user in a browser released within the last couple of years - I guess that would be discussed in more detail on the tracker issue related to such a feature. It would probably be fine if the particular task/feature could only be achieved in a newer browser depending on what it actually was.

              Show
              danmarsden Dan Marsden added a comment - no - but it would be nice if a feature like that didn't completely break Moodle for a user in a browser released within the last couple of years - I guess that would be discussed in more detail on the tracker issue related to such a feature. It would probably be fine if the particular task/feature could only be achieved in a newer browser depending on what it actually was.
              Hide
              sbourget Stephen Bourget added a comment -

              What about having 2 different levels of published browser support?

              "Certified Browsers" - that have been tested by Behat (the last 2 versions of each browser)
              "Supported Browsers" All versions of the browsers that were released in the last X months (maybe 12 months). These browsers would not be tested by Behat, but would be used as a baseline deciding which features are supported by browsers. (Meaning the we try not to intentionally break these browsers) This could be important when looking at browsers like chrome / Fire Fox which would have had 2 new releases in a span of 3-months, It would also allow institutions that have strict browser requirements like ESR to continue using them.

              Show
              sbourget Stephen Bourget added a comment - What about having 2 different levels of published browser support? "Certified Browsers" - that have been tested by Behat (the last 2 versions of each browser) "Supported Browsers" All versions of the browsers that were released in the last X months (maybe 12 months). These browsers would not be tested by Behat, but would be used as a baseline deciding which features are supported by browsers. (Meaning the we try not to intentionally break these browsers) This could be important when looking at browsers like chrome / Fire Fox which would have had 2 new releases in a span of 3-months, It would also allow institutions that have strict browser requirements like ESR to continue using them.
              Hide
              gb2048 Gareth J Barnard added a comment - - edited

              Policies can be a good thing and a bad thing, so stop faffing around and making a rod for your own back. As browser technology is out of your control don't create a policy rule around it. Instead 'adapt', change the release procedure to have a 'decision' point in the first two weeks of the major release development where the browser support is decided upon and then communicate it. Then everybody will know what to expect and you'll be able to make an informed decision at an appropriate time.

              Show
              gb2048 Gareth J Barnard added a comment - - edited Policies can be a good thing and a bad thing, so stop faffing around and making a rod for your own back. As browser technology is out of your control don't create a policy rule around it. Instead 'adapt', change the release procedure to have a 'decision' point in the first two weeks of the major release development where the browser support is decided upon and then communicate it. Then everybody will know what to expect and you'll be able to make an informed decision at an appropriate time.
              Hide
              emerrill Eric Merrill added a comment - - edited

              I ran some statistics against some of our logs for the last 4 weeks (from one of our load balanced nodes, containing about 6.6M hits)

              By these numbers, 85.9% of our users fall within that policy (supported), 11.1% are not supported, and 3.1% are unknown.

              The biggest unknown we see is "MSEdge 13.10586" at 2.24% of our traffic. I list it as unknown, as they use two major versioning schemes (see the wiki page), so I'm not sure what counts as the "2 most recent releases".

              As for our unsupported, we see:

              FF 8.0 1.68%
              IE 8.0 1.60%
              Chrome 49 1.41%
              FF 45 1.03%
              FF 44 0.69%
              Chrome 44 0.68%

              I've posted the fill list here: https://gist.github.com/merrill-oakland/f28ccaba3374aaa8480e01490e95451b
              I tried to collapse some of the version numbers, particularly Chrome, since they are very verbose with different versions.

              Show
              emerrill Eric Merrill added a comment - - edited I ran some statistics against some of our logs for the last 4 weeks (from one of our load balanced nodes, containing about 6.6M hits) By these numbers, 85.9% of our users fall within that policy (supported), 11.1% are not supported, and 3.1% are unknown. The biggest unknown we see is "MSEdge 13.10586" at 2.24% of our traffic. I list it as unknown, as they use two major versioning schemes (see the wiki page), so I'm not sure what counts as the "2 most recent releases". As for our unsupported, we see: FF 8.0 1.68% IE 8.0 1.60% Chrome 49 1.41% FF 45 1.03% FF 44 0.69% Chrome 44 0.68% I've posted the fill list here: https://gist.github.com/merrill-oakland/f28ccaba3374aaa8480e01490e95451b I tried to collapse some of the version numbers, particularly Chrome, since they are very verbose with different versions.
              Hide
              damyon Damyon Wiese added a comment -

              Thanks Eric. From your list of unsupported browsers IE 8, FF 8 are already not supported by Moodle 3.1.

              I notice there are no IE9 and IE10 browsers in the list which I guess is due to Microsofts new aggressive update policy and backs up the argument to go with IE11 and Edge (all versions of edge).

              Chrome 44 was released > 1 year ago

              Chrome 49 was released in march. Even if we don't list it as supported - it is likely it will be 100% feature compatible.

              Firefox 45 was released in march. Even if we don't list it as supported - it is likely it will be 100% feature compatible. Note specifically with firefox versions the biggest problem we have is finding a version of selenium that will work with the specific firefox version. This is just a testing issue and won't affect users.

              Show
              damyon Damyon Wiese added a comment - Thanks Eric. From your list of unsupported browsers IE 8, FF 8 are already not supported by Moodle 3.1. I notice there are no IE9 and IE10 browsers in the list which I guess is due to Microsofts new aggressive update policy and backs up the argument to go with IE11 and Edge (all versions of edge). Chrome 44 was released > 1 year ago Chrome 49 was released in march. Even if we don't list it as supported - it is likely it will be 100% feature compatible. Firefox 45 was released in march. Even if we don't list it as supported - it is likely it will be 100% feature compatible. Note specifically with firefox versions the biggest problem we have is finding a version of selenium that will work with the specific firefox version. This is just a testing issue and won't affect users.
              Hide
              emerrill Eric Merrill added a comment -

              Yeah, it would mainly be how aggressive we are with adopting new browser features. Also, to be clear, I wasn't making argument against this change - just providing information.

              In fact, talking it over here with my boss, we feel this new policy would be good.

              Show
              emerrill Eric Merrill added a comment - Yeah, it would mainly be how aggressive we are with adopting new browser features. Also, to be clear, I wasn't making argument against this change - just providing information. In fact, talking it over here with my boss, we feel this new policy would be good.
              Hide
              poltawski Dan Poltawski added a comment -

              But should we be blocked from using new browser features that are supported in the last two versions of all major browsers ?

              how aggressive we are with adopting new browser features

              I think that the biggest barrier for feature adoption is actually multi-vendor support. While Chrome and Firefox are pumping out new support for shiny things to production builds all the time, with webkit (mobilesafari on iOS and Safari on OSX) I think there current much less-agressive release schedule which will counter that in terms of adopting new shiny things. So I think think people shouldn't get too caught up on Chromes release schedule meaning a few month version of chrome would not usable (Though again, this backs the notion of not talking about this in terms of 'support').

              Show
              poltawski Dan Poltawski added a comment - But should we be blocked from using new browser features that are supported in the last two versions of all major browsers ? how aggressive we are with adopting new browser features I think that the biggest barrier for feature adoption is actually multi-vendor support. While Chrome and Firefox are pumping out new support for shiny things to production builds all the time, with webkit (mobilesafari on iOS and Safari on OSX) I think there current much less-agressive release schedule which will counter that in terms of adopting new shiny things. So I think think people shouldn't get too caught up on Chromes release schedule meaning a few month version of chrome would not usable (Though again, this backs the notion of not talking about this in terms of 'support').
              Hide
              damyon Damyon Wiese added a comment -

              Some stats from the last 2 months on Moodle cloud -

              Highest browsers by % ignoring bots and browsers less than 0.5% of the total etc.

              25.5% chrome: 51
              16.0% chrome: 52
              9.4% firefox: 47
              5.3% ie: 11
              2.9% safari: 9
              2.2% chrome: 49
              2.1% edge: 13
              2.0% mobile safari: 9
              1.8% firefox: 48
              1.3% chrome: 44
              1.1% chrome mobile: 51
              0.7% chrome: 50
              0.6% chrome mobile: 52
              0.5% mobile safari ui/wkwebview: 9

              (they are classified into browser families and major versions)

              Show
              damyon Damyon Wiese added a comment - Some stats from the last 2 months on Moodle cloud - Highest browsers by % ignoring bots and browsers less than 0.5% of the total etc. 25.5% chrome: 51 16.0% chrome: 52 9.4% firefox: 47 5.3% ie: 11 2.9% safari: 9 2.2% chrome: 49 2.1% edge: 13 2.0% mobile safari: 9 1.8% firefox: 48 1.3% chrome: 44 1.1% chrome mobile: 51 0.7% chrome: 50 0.6% chrome mobile: 52 0.5% mobile safari ui/wkwebview: 9 (they are classified into browser families and major versions)
              Hide
              damyon Damyon Wiese added a comment -

              So - from the data we got from Eric and could + suggestions above it sounds like a generic policy is not going to work. I've changed the title of this issue to reflect it's just about updating the list for Moodle 3.2.

              I will update the description with a new proposed list of browsers which eliminates the very rarely used browsers which cause the most problems and still supports a wide range of browsers still in use.

              Show
              damyon Damyon Wiese added a comment - So - from the data we got from Eric and could + suggestions above it sounds like a generic policy is not going to work. I've changed the title of this issue to reflect it's just about updating the list for Moodle 3.2. I will update the description with a new proposed list of browsers which eliminates the very rarely used browsers which cause the most problems and still supports a wide range of browsers still in use.
              Hide
              damyon Damyon Wiese added a comment -

              ping!

              Show
              damyon Damyon Wiese added a comment - ping!
              Hide
              poltawski Dan Poltawski added a comment -

              Is the ping directed in the direction of integrators? We have been discussing this internally and I think we are fine with this list of browsers.

              We are just discussing a potential change in how we describe the browsers - along the lines of the discussions here about not 'closing the door' on older versions - but reflecting the reality of how the browsers are actually supported.

              Show
              poltawski Dan Poltawski added a comment - Is the ping directed in the direction of integrators? We have been discussing this internally and I think we are fine with this list of browsers. We are just discussing a potential change in how we describe the browsers - along the lines of the discussions here about not 'closing the door' on older versions - but reflecting the reality of how the browsers are actually supported.
              Hide
              poltawski Dan Poltawski added a comment - - edited

              The idea behind a change in terminology is to adapt to the practical reality of browser support in Moodle today. From my point of view, I want to:

              1. More accurately reflect the browser support situation to our users (don't scare them off unnecessarily, like a 'hard' not supported comment has the potential to do)
              2. But still communicate when real problems are likely to come up
              3. Let developers embrace the 'modern browser landscape' and innovate quickly by focusing most of their efforts on the majority of our users (current browser versions)

              This is the terminology I have come up with, comments are welcome:

              User guidance (would be in release notes and so on)

              Moodle is compatible with any standards compliant web browser. We regularly test Moodle with the following browsers:

              Desktop:

              • Chrome
              • Firefox
              • Safari
              • Edge
              • Internet Explorer

              Mobile:

              • MobileSafari
              • Google Chrome

              For the best experience and optimum security, we recommend that you keep your browser up to date. https://whatbrowser.org

              Note: Legacy browsers with known compatibility issues with Moodle 3.2:

              • Internet Explorer 10 and below
              • Safari 7 and below

              Developer guidance:

              Developers are encouraged to embrace modern web technologies when a feature has been implemented by all major vendors (Chrome/Firefox/Edge/Safari). We encourage our users to run on up to date browsers, developers should focus the bulk of their attention on supporting these users when implementing new functionality.

              Questions to ask, when deciding can I use 'feature-x'?

              • What is the impact of this feature not being available?
                • If it breaks the site, you must ensure it is available in firefox/chrome releases over the last 1y and Safari/IE releases not mentioned in our compatibility issues
                • If it's just 'nice to have' cosmetic issue you do not need to be strict
              • Is it supported by all major vendors on all platforms?
                • If not: You can't use this feature yet
              Show
              poltawski Dan Poltawski added a comment - - edited The idea behind a change in terminology is to adapt to the practical reality of browser support in Moodle today. From my point of view, I want to: More accurately reflect the browser support situation to our users (don't scare them off unnecessarily, like a 'hard' not supported comment has the potential to do) But still communicate when real problems are likely to come up Let developers embrace the 'modern browser landscape' and innovate quickly by focusing most of their efforts on the majority of our users (current browser versions) This is the terminology I have come up with, comments are welcome: User guidance (would be in release notes and so on) Moodle is compatible with any standards compliant web browser. We regularly test Moodle with the following browsers: Desktop: Chrome Firefox Safari Edge Internet Explorer Mobile: MobileSafari Google Chrome For the best experience and optimum security, we recommend that you keep your browser up to date. https://whatbrowser.org Note: Legacy browsers with known compatibility issues with Moodle 3.2: Internet Explorer 10 and below Safari 7 and below Developer guidance: Developers are encouraged to embrace modern web technologies when a feature has been implemented by all major vendors (Chrome/Firefox/Edge/Safari). We encourage our users to run on up to date browsers, developers should focus the bulk of their attention on supporting these users when implementing new functionality. Questions to ask, when deciding can I use 'feature-x'? What is the impact of this feature not being available? If it breaks the site, you must ensure it is available in firefox/chrome releases over the last 1y and Safari/IE releases not mentioned in our compatibility issues If it's just 'nice to have' cosmetic issue you do not need to be strict Is it supported by all major vendors on all platforms? If not: You can't use this feature yet
              Hide
              matteo Matteo Scaramuccia added a comment -

              Show
              matteo Matteo Scaramuccia added a comment -
              Hide
              mudrd8mz David Mudrák added a comment -

              Thanks Dan. I like wording as it sends a clear message to both users and developers. Good direction to have these things communicated clearly.

              The pedant in me would raise:

              been implemented by all vendors (Chrome/Firefox/Edge/Safari)

              Could we use something like "major vendors" or so? As per wikipedia, "A vendor, or a supplier, is a supply chain management term that means anyone who provides goods or services to a company or individuals." (note that "anyone" there). A friend of mine once implemented a browser (and by the way he reported it was quite challenging). Surely we do not want to wait for him (and Lynx authors, with all the respect) to implement latest HTML features before we allow them in Moodle.

              Show
              mudrd8mz David Mudrák added a comment - Thanks Dan. I like wording as it sends a clear message to both users and developers. Good direction to have these things communicated clearly. The pedant in me would raise: been implemented by all vendors (Chrome/Firefox/Edge/Safari) Could we use something like "major vendors" or so? As per wikipedia, "A vendor, or a supplier, is a supply chain management term that means anyone who provides goods or services to a company or individuals." (note that "anyone" there). A friend of mine once implemented a browser (and by the way he reported it was quite challenging). Surely we do not want to wait for him (and Lynx authors, with all the respect) to implement latest HTML features before we allow them in Moodle.
              Hide
              mudrd8mz David Mudrák added a comment -
              Show
              mudrd8mz David Mudrák added a comment - https://xkcd.com/1494/
              Hide
              matteo Matteo Scaramuccia added a comment -

              +1 to major vendors

              Show
              matteo Matteo Scaramuccia added a comment - +1 to major vendors
              Hide
              poltawski Dan Poltawski added a comment -

              Sure, I edited it.

              Note, while we are being pedantic - I also think 'any standards compliant web browser' is not the greatest term either, but I think it conveys the right sort of message and couldn't think of a better way of putting it.

              Show
              poltawski Dan Poltawski added a comment - Sure, I edited it. Note, while we are being pedantic - I also think 'any standards compliant web browser' is not the greatest term either, but I think it conveys the right sort of message and couldn't think of a better way of putting it.
              Hide
              stronk7 Eloy Lafuente (stronk7) added a comment -

              +1

              Show
              stronk7 Eloy Lafuente (stronk7) added a comment - +1
              Hide
              damyon Damyon Wiese added a comment -

              Seems we have agreement here.

              Closing fixed for 3.2 with release_notes label so it comes up in Marinas list when she writes the release notes.

              Show
              damyon Damyon Wiese added a comment - Seems we have agreement here. Closing fixed for 3.2 with release_notes label so it comes up in Marinas list when she writes the release notes.

                People

                • Votes:
                  1 Vote for this issue
                  Watchers:
                  25 Start watching this issue

                  Dates

                  • Created:
                    Updated:
                    Resolved:
                    Fix Release Date:
                    5/Dec/16