Include Firefox ESR as Supported Browser

[John_Lowe]

  Idea will be open for vote May 5 - August 5 Learn more about voting...

Firefox has a rapid release cycle - every 5 or 6 weeks.  Unfortunately, for people who support faculty desktop machines and student lab machines/environments, keeping the browsers updated to keep within the latest 3 releases for Canvas support becomes a large task.

However, Firefox offers an "Extended Support Release"  - this release does not add new features, just security updates on a regular basis.  If Canvas were to include the ESR versions as supported browsers, it would make managing lab and faculty machines much easier for IT departments everywhere.

Mozilla's FAQ on the ESR release - http://www.mozilla.org/en-US/firefox/organizations/faq/

  Response from Instructure

Comment from Scottd at Canvas on May 28 in the comments below:

Thank you to everyone who took the time to carefully read through and comment on this feature idea (in the current forum and, many of you, in the old forum previously).  This is obviously an important issue for a lot of Canvas users, particularly in large computer lab deployments.  After weighing all the opinions expressed, we have decided to continue with our decision not to support the Firefox ESR browser.

Considerations that supported this decision:

• Relatively few of the people logging into Canvas currently use the FF ESR browser (less than one percent by recent count).
• Because Firefox is relatively stable when compared to other popular browsers, users of ESR rarely encounter errors that would be alleviated if we quality checked every change to Canvas against this browser.
• Not releasing features that take advantage of newer web technologies because they would not run reliably in a year old browser would necessitate delaying the release of new features to Canvas users who do not use ESR

Several comments in the thread make reference to the alternate idea of making the unsupported browser warning message configurable or less intrusive as a possible compromise, which would be another viable feature idea.  If you like this idea, please consider voting for Dismiss the Unsupported Browser warning during a browsing session, starting June 3rd.

[david_taylor]

Yes, please!

[John_Lowe]

This is open for voting now.  Please vote! Canvas Admins​

[macderm]

I don't know why this even needs a vote - it's a no brainer.  Canvas needs to support ESR because it is widely used in classrooms, labs and other educational settings with managed computers

[jasonrw]

Yes. Please support the ESR version of Firefox. I use it in my classrooms and labs and get a flood of complaints each semester regarding the issue. Thanks

[ula]

Yes, please do support this version.

[scheydec]

Necessary for campus computer labs!  Please support this!

[jtreat]

Our faculty complain that they can't use Firefox to use Canvas in our classrooms — even though Firefox ESR has every functionality they need. The orange message that this browser is not supported keeps popping up every few seconds. You either have to keep dismissing it or just endure having it on the screen while you use Canvas. It's really annoying.

[david_burns]

Like macderm​​ says, it should be a no-brainer.

:smileyplus::smileyplus::smileyplus:Please support Firefox ESR!:smileyplus::smileyplus::smileyplus:

[dperpich]

"Firefox ESR is intended for groups who deploy and maintain the desktop environment in large organizations such as universities and other schools, county or city governments and businesses."

Seems like a no-brainer that these two core tools (the institutional browser and the institutional LMS) should play nicely together.  Rather Canvas be a little behind the breakneck and not throw an error message with the university and school browsers.

"[ESR are not for] Individual users who always want the latest features, performance enhancements and technologies in their browser without waiting for them to become available in ESR several development cycles later."

[owen]

Would be nice also if Debian Linux's Iceweasel (Firefox without proprietary branding) didn't trigger the unsupported browser warning, since it's essentially the same browser as Firefox.  (And is currently at the ESR version.)

[James]

In practice, this sounds like a great idea. In theory, not so much (yes, I know I said that backwards).

In practice, it means that IT departments everywhere can keep software on their computers and not have to worry about stuff breaking in the middle of a semester. Sounds perfect.

Wait, I've heard that argument before. It was the same argument made against Canvas' release cycle. Some tried to squash the advance of Canvas by saying they should only release new versions between semesters. One problem with the argument was that there is always a class going on somewhere; we have inter-term courses, so there isn't a dead time for us. Another issue is that we would have to wait for all of the great things, and not so great things, that Canvas implements now, rather than having to wait for two times a year.

Also throw in that I can't reliably run Adobe Flash or Java on my school's Firefox installation because those versions are outdated and insecure and Firefox keeps on warning about those. Yeah, that's probably something the IT person should figure out, but there are other, more pressing issues.

Theoretically, you're asking Canvas to provide support a year-old browser. That can (hence the theoretical) keep them from implementing new features. It also forces them to keep old code around to support old browsers. It leads to code bloat, multiple implementations, and additional bugs.

You argue that Internet Explorer 10 is supported and it was released in October 2012. My experience is that support for Internet Explorer is buggy. We tell our students not to use it.

The main push, in my mind, for people using Firefox ESR is because new releases tend to be unstable. There is a 2 cycle version where IT staff can check-out a new version before the old ESR is abandoned. For example, Firefox 38 becomes available May 19, but the ESR 31 remains available until August 11. Another issue with Firefox's releases is that their ESRs aren't more stable than others, they just hang around longer. Their website says that security releases are made; it doesn't talk about bug fixes during that one year period. In other words, ESR-38 is just another Firefox, not a better Firefox.

We want our students to have the latest versions of software on their home computers. We want them to keep their plugins up to date. We stress updating their antivirus or antimalware software. Yet, when the students come to school and use our computers, they don't get the latest versions of software, so it's different from their experience at home.

The issue is whether or not Canvas should provide long-term support for a year-old version of a browser that may be up to 8 releases behind by the time it's retired. What if supporting an old version takes resources away from developing or improving Canvas?

All of this said, I think Firefox going to a 6 week release cycle was a mistake. The initial releases are buggy. The new features aren't needed. Memory usage increases and performance decreases. I miss the old Firefox. I find the new one hard to tell apart from Chrome and the distinction blurs with every new release. As much as I hate to say it, I think Mozilla is shooting themselves in the foot. The Firefox ESRs just prolong that pain.

So yes, even though I wear an IT hat and it pains me to have to say this (but I blame Firefox, not Canvas), but after thinking about it, I'm going to have to vote No and Canvas should do other things besides support Firefox ESR.

[John_Lowe]

Thanks, James!  I appreciate reading your thoughtful response.  I would like to ask a follow-up question related specifically to your comment about Internet Explorer 10 and the prior one about keeping Instructure from implementing new features.  If Instructure still has to keep their releases compatible (which they do despite what we may want our students to use) with the big mainstream web-browsers (Internet Explorer and Safari) with back versions that are often much older than any supported Firefox ESR version, why would supporting an institutional-friendly version of Firefox be any worse or different for the Canvas development cycle than supporting these much older mainstream browsers?

If the Firefox ESR cycle jumps from Firefox 38 to Firefox 45, what about these rapid in-between versions are better for Instructure to develop for?  For example, is there something that would make Firefox 41 better to develop for that can't be developed for Firefox 38 keeping in mind that Firefox 38 is still years ahead of the other mainstream browser release dates?

It would seem that if Instructure is still going to support the older mainstream browsers, an easy solution to this problem would be to treat Firefox in much the same way.  For example, they could support Firefox 38 (ESR or higher) followed later by Firefox 45 (ESR or higher). Our home users may be able to keep their browsers constantly updated, but that isn't always possible on large deployments of institutional computers where they could more easily manage a Firefox ESR 38 and later a Firefox ESR 45.

[scottdennis]

Hi  @James ​,

I commend you for providing a clear and well considered rationale for why you chose to down vote this idea - an etiquette best practice that we will probably soon add to the 'How Feature Voting Works' document.

[James]

Ya know, I told my wife I didn't feel I had done a good job explaining things

The majority of your focus seems to be on the absolute age of the browser, rather than it's relative position. You're equating old Internet Explorer with old Firefox. while Canvas is using versions as the comparison. Either way, in my mind, that's not the major issue, although it does impact features that can be developed. The main issue that I see is support..

Let's start with a definition of what "supported browser" means. I posted something similar to another user asking about Iceweasel when I redirected him over here to this feature request so he could vote for it.

A supported browser should be one that Instructure will provide support for. That means that if there are problems, they try to fix them. They should do testing on the supported browsers to make sure that functionality isn't broken during an upgrade (I'm not impressed with this aspect of Canvas development). If someone is running an unsupported browser, the first line of support is "upgrade your browser" and see if that fixes the issue. Each version of a browser that is supported requires additional development, additional testing, additional technical support, additional time, additional resources, and additional money (all of which are limited, so putting it in one place means taking it away from somewhere else).

Officially, Canvas supports the two latest releases of each of the major browsers. That doesn't mean that older versions won't work and work fine. The fact that MSIE 10 came out in 2012 means that Canvas doesn't have to do much work to keep it supported with existing functionality. On the other hand, Firefox's rapid release means increased testing for them. But in each case, they are only supporting two versions of each browser - the latest and the previous one. What you are asking for is a deviance from that. Support the last two versions of Firefox and one that's a year old - that makes 3. That's asking for preferential treatment, so right there is one difference. And according to NetMarketShare, Firefox 31 has a 0.36% share of the desktop browser market. Unfortunately, that doesn't separate educational users from non-educational users.

As for MSIE, I cannot distinguish whether Canvas features don't work because it's MSIE (and MS has never adhered to the standards like the other browsers) or because the technology is 2.5 years old. It may be a little bit of both. That's also why I threw that argument into the "theoretical" portion. I don't know what goes into all the slick new features that Canvas puts out; I still write all my code to be XHTML 1.0 compliant, using only web standards (no CSS, HTML, or JavaScript hacks), with a major emphasis on usability and accessibility. But Canvas is far more awesome than anything I've written, majorly due to using new technologies.

Supposedly, a recent browser supports more and newer features than an older one. When functionality is built into the browser, it reduces the amount of workarounds required on the programmers end. Take, for example, rounded corners. which is now supported by 91% of all browsers, but wasn't supported with MSIE until version 9. It used to take JavaScript libraries to implement it on MSIE and it wasn't worth loading jQuery just so the pages would look cool. So I would design pages that used them and just recognized that people using old browsers would have a usable experience but not identical experience. Adding JavaScript work-arounds to provide uniform functionality and appearance increases the opportunity for buggy code.

You asked about what makes FF41 better than FF38? That is difficult to answer right now, since FF38 is just now coming out, but it appears that Fetch and the Web Open Font Format will be available in FF41​ that aren't available in F38. However, there are 14 new features, with added support for 3 others, in FF38 over FF31. I don't know which of those might make life easier for Canvas. The improved support for CSS Filter effects, the matches() DOM method, and the MPEG-4/H.264 video format, might be used.

Back in the day, we used to provide functionality for people who had JavaScript disabled. The interfaces were still usable, but they weren't nearly as nice or user-friendly. Now, probably starting around Web 2.0, JavaScript is more of a requirement than a nicety. Unfortunately, I use some other classroom management systems that only provide functionality through Javascript and don't have an API like Canvas to do things on the backend. So, I either use AutoHotKey to automate clicks in the browser, which is very susceptible to small deviations in layout (I still use AHK when adding a Rubric from a spreadsheet or assigning peer reviews), or I use CasperJS to simulate a browser. So, use old technology and it should work, probably not as well, and definitely not as polished as the new technology allows.

The idea of functional but not equivalent interfaces allows Canvas to be on the leading edge of features rather than stuck with what MSIE allows because it's the oldest supported browser. If you're using Firefox 31-ESR, you may have similar functionality, but things not work or look exactly the same as they do in current browsers. Some things work fine in MSIE, but submitting assignments is problematic and the first question our online support team asks a student when they say they have trouble submitting is "Are you using Internet Explorer?"

But as I write this, a thought occurs to me. Might we be having the wrong discussion? That's how I ended up on this page to start with -- I was telling another person who requested that Iceweasel be supported that his feature request might be better addressed here because it's essentially the same one and this one was already active with lots of votes. Iceweasel is Firefox ESR without the branding.

What is the problem with Firefox 31-ESR? Is it because it's non-functional or because it gives an annoying and frequent warning that it's not an officially supported browser? You make the argument that FF is years ahead of the other major browser (most recent surveys show Chrome as the major browser and several show Firefox in 3rd place behind both Chrome and Internet Explorer). So that makes it sound like the issue is not one of things failing to work in FF31-ESR, but that Canvas is saying it's unsupported.

So, rather than having Canvas support, as in officially support, Firefox ESR, why not have a configuration setting that would allow the user to specify which unsupported versions of browsers they would like to suppress the warning for? This could be as simple as checkbox that says "Suppress unsupported browser warnings for extended service release versions" or "Suppress warning for Firefox ESR" (since the major issue appears to be with Firefox's rapid releases, not Chrome's) or as complicated as having multiple checkboxes to select which ones to allow.

Then Canvas can officially support the last two versions of a browser and the onus of support is shifted to the institution who wants to run older software; realizing that it will probably work fine but that the interface might be diminished. It might even be possible to put in something in the global JavaScript or CSS files that would suppress the warnings for you. But I still think the warning is a good thing to have, so I probably wouldn't want to suppress it.

This solution is not without potential problems. One would be that whenever a student sends a help ticket through to Canvas, they're going to see "Firefox 31-ESR" and say "You're running an unsupported version, you should upgrade to the latest version." Of course, the school won't be willing to do that, but that is really no different than it is now, so maybe it's not as big of a problem as it could be. Another potential problem if you allow old versions is that someone will forget to uncheck an old version and in five years, someone will be using FF31-ESR and wondering why they didn't get an unsupported browser warning when it's obviously not working correctly. Also, checking which browsers are unofficially supported would require updating, while a "Support the latest version of Firefox ESR" could be determined on Canvas' end, relieving the institutions of that burden.

Another, somewhat extreme, possibility is for the school to drop support for Firefox because of the stability issues. We've already made Internet Explorer about as difficult to find as we can on our school computers.

The funny thing about all this is that with a prior LMS that we hosted ourselves, I actually went into the configuration and told it which browsers were supported. The issue there, though, was that software updates came so infrequently that it was the newer versions that were getting the warnings about not being supported.

Thank you for asking for clarification. When I first voted no, I was waivering between supporting and opposing, but the more I write, the more I am convinced I made the right call. Canvas should not make an exception of the two version rule for Firefox ESR.

[owen]

Perhaps a compromise solution would be to make the unsupported browser warning a little less obtrusive.  Could it be limited to the banner at the top, rather than on sub-pages displayed in the center section?  And maybe small enough not to cover up menus?  The text of the warning could also be modified in such a way that users who don't have control of the software on the machine they're using would understand that, even though they're using an unsupported browser, Canvas might still work fine.

[James]

I like those suggestions, owen.

I haven't used an unsupported browser, since Canvas came along, so I had to do some research to see exactly what people are seeing. I started by loading Epiphany 3.10.3 on Ubuntu, but strangely, it was recognized as Safari 8 and had no problems. That means, David, that there's a good chance that a new version of Iceweasel is available in Debian, that it might work and it really was related to Firefox ESR being unsupported instead of Iceweasel. In fact, I'm getting Firefox 38 available messages as I type this, so hopefully you can test that soon.  I finally ended up a Firefox add-on to change the user-agent and now I see what the ruckus is about.

Anyway, simple fix:

Use a cookie so that the warning shows up only once per session. Once the user clicks the X to close it, it's gone until the next browser session. This would go a long way towards reducing irritation. Then, even if it did overlap a menu, it could easily be dismissed. One time per session isn't bad.

Also, change the link in the message to use the new Canvas Guides, instead of the old one.

[John_Lowe]

This sounds like a very reasonable accommodation -- using session cookies to keep the warning suppressed.  Pehaps this could be one option that Instructure considers for this issue.

I'm going to toss one more idea out there to see where or if it sticks.  Perhaps, you are right that two-versions of major browsers is a good policy.  I can certainly see where that is beneficial.  But would it be reasonable for Instructure to treat the ESR releases then as a distintly separate browser -- although one that is small scale in public use but INCREDIBLY commonplace by the institutions served by Instructure?

I don't know anyone that uses Firefox ESR at home.  I do know 3 campus lab support techs that maintain well over 2,000 public computers in over 30 locations.  I know 2 more classroom technology service technicians that maintain the classroom computer in almost every classroom on our campus.  For them, Firefox ESR is the browser of choice because it *is* better than IE and Safari and they simply cannot keep up with the Chrome and non-ESR release cycles. 

For this reason, perhaps Instructure shouldn't look at ESR as just an older Firefox but instead look at it as a distinct, institutionally-focused, standard browser in higher education (that happens to be strikingly similar to an already supported home browser).

[awilliams]

Even though it's over the 30 vote threshold, I'm up-voting this in support of the thoughtful opinions offered by  @John_Lowe ​,  @James ​, and owen​. I will leave it up to Instructure to decide exactly how to handle it. I will add that I think the single warning per session would be my vote for best compromise. For what it's worth we recommend Chrome at our institution and users can update Chrome on their own.

[david_taylor]

James,

You need to look at it from a computer lab and classroom perspective.  It is not feasible to re-image hundreds and hundreds of computers in the middle of a semester just to get the latest version of Firefox.  THAT is the reason they go with the ESR.  Sure, it is easy to tell professors and students to upgrade their personal machines.  But classroom and lab machines that are locked/imaged cannot be done this way.  Look at it broadly, and you'll see that there *is* a reason for this to go through and to *not* downvote it.

[scottdennis]

This is an amazingly productive conversation.  Thank you to those of you pouring your time and effort into it.  Ironically, unless I am mistaken the reason the unsupported browser warning is so aggressive is due originally to a feature request, asking that it be more noticeable!

I, personally, like the solution of making the warning suppressible, either across the board at the account or sub-account level or as a per-browser setting.