Provide a mechanism to detect if the user's browser is supported

[PolymerCommunityBot]

Issue by sorvell
Thursday Aug 07, 2014 at 17:17 GMT
Originally opened as https://github.com/Polymer/platform-dev/issues/40

---

When a browser is unsupported, typically the user will see a slew of errors and/or a blank page. The server/userAgent can be used to detect if the browser is supported, but it would be nice to be able to do this at the client level.

[ckortekaas]

If it helps anyone who needs to provide more than a blank screen to unsupported browser users, and you can't wait until Polymer 1.0, here's how we've attempted to deal with this: uqlibrary/uqlibrary-home@7d97c86

[jokeyrhyme]

Not sure if it's worth a separate GitHub Issue, but it'd also be nice to document how to determine whether or not WebComponents.js is needed at all.

So with a few ifs in JavaScript, we can either:

• load both Polymer and WebComponents.js (modern browser)
• load Polymer by itself (perfect browser)
• non-Polymer fallback or browser incompatibility notice (old browser)

What conditions should be in those ifs?

[coreyfarrell]

I think we just need a 'no-webcomponents' custom element. I've created a live example on Plunker.

I've tested this on Chromium 41 and Firefox 37, and for both browsers with the webcomponents-lite.js script removed. For Chromium the page displayed only. Firefox displayed when webcomponentsjs was loaded, and displayed when the script was removed. I don't have access to any unsupported browsers, but I would expect this to work across the board - assuming that same browser can handle loading Plunker.

[jokeyrhyme]

@coreyfarrell Plunker doesn't work in IE8 (completely broken) or IE9 (doesn't load desired code), so I couldn't test it there. :S

[coreyfarrell]

@jokeyrhyme any recommendation for a place to post that will work in IE8/IE9?

[addyosmani]

Afaik, JSBin shouldn't have this issue.

[coreyfarrell]

JSBin doesn't seem to support multiple HTML files. Plunker seems to have an embedded link that looks much simpler, @jokeyrhyme can you access http://embed.plnkr.co/5rQwzOfvRHZXbLJH3MAR/preview from IE8/9?

[jokeyrhyme]

@coreyfarrell I'm just using the official Microsoft VMs from https://modern.ie/

http://embed.plnkr.co/5rQwzOfvRHZXbLJH3MAR/preview
I tested in IE10 just for kicks and as that is a supported target for Polymer, everything works fine.
In IE9, Plunker itself redirects to a hash-bang URL and then 404s (see screenshot). :S
In IE8, Plunker itself just dies completely, leaving only static HTML remnants on the page.

Can you talk a bit about how the "no-webcomponents" element works? I'm assuming that it is not a WebComponent (Polymer or otherwise) otherwise it wouldn't function.

[coreyfarrell]

I've created a repo for: https://github.com/coreyfarrell/no-webcomponents.

Pretty simple, the conents of 'no-webcomponents' only display for browsers that do not support webcomponents. If webcomponents are supported, 'display:none' from no-webcomponents.html takes effect. The reverse has to be done from a stylesheet supported by the old browser, to hide any text from webcomponents that would be displayed per default handling of unknown elements by old browsers.

Normal the

in index.html would be one or more custom elements for your app.

[jokeyrhyme]

@coreyfarrell unless I'm mistaken, your no-webcomponents WebComponent actually needs HTML Imports and Custom Elements to function, whether that means native browser implementation (Chrome-only) or the WebComponents (Lite) poly-fill. I'm not sure this solves the problem in the original post.

[jokeyrhyme]

@coreyfarrell put another way, it's similar to writing an ES6 detector in ES6, which won't function at all in ES5 or ES3 browsers.

[coreyfarrell]

It's backward though. The no-webcomponents element displays like a div on old browsers, successful import of the webcomponent code will cause it to be hidden.

[ckortekaas]

FWIW, we ended up separating our Polymer 'Preloader' that checks for browser compatibility into this try/catch on DomContentLoaded/polymer-ready check here: https://github.com/uqlibrary/uqlibrary-elements/blob/master/resources/common/preloader.js#L76

We had to detect hardware, operating system and browser combinations and give special messages as you can see if you scroll down.

I'm sure you guys could come up with something smarter and more light-weight. Especially since this requires a jquery-plugin 'pgwBrowser' to get the conditional information, and therefore requires jQuery - which is probably a bit overbloated JUST to check if someone can run Polymer!

[ckortekaas]

I forgot to add that here is an example of it in action:

https://github.com/uqlibrary/uqlibrary-home/blob/master/index.html#L62

Note 'loading' spinner and conditional loading of webcomponents.js too

[jokeyrhyme]

@coreyfarrell ah, good call. Yes, I see now. :) This solves the "blank page" problem from the original post. It doesn't stop the JavaScript from being loaded at all though, so the console will still have errors.

@ckortekaas I wrote these 2 detectors to help me avoid loading WebComponents + Polymer:

• https://github.com/jokeyrhyme/is-es5-supported
• https://github.com/jokeyrhyme/is-dom4-supported

[coreyfarrell]

@jokeyrhyme correct, I guess for me console errors on an unsupported browser are a non-issue, as long as it doesn't interfere with display of a message specifically for unsupported browsers.

[pensierinmusica]

Hi @ckortekaas, in #26 (comment) you mentioned:

If it helps anyone who needs to provide more than a blank screen to unsupported browser users, and you can't wait until Polymer 1.0, here's how we've attempted to deal with this

What does Polymer 1.0 do to check browser support? Does it offer any API? I couldn't find any reference in the official docs. Thanks!

[ckortekaas]

Hi @pensierinmusica, when I wrote that comment I think my teams expectation was that polymer 1.0 would have features like that, but I think we had the wrong idea. We are still implementing these checks ourselves.

[ebidel]

Here's one way you can lazy load the wc.js polyfills if the browser needs them:
https://github.com/ebidel/polymer-gmail/blob/e40b3bbe64bbee79a671693b051b8fbf7b4874d4/scripts/app.js#L51-L64

[pensierinmusica]

@ckortekaas, I see, thanks for the quick feedback! How do you check if Polymer 1.0 is fully supported though?

@ebidel, thanks for the tip! Besides lazy loading wc.js, I'd like to check if the user browser supports Polymer (i.e. if it properly supports wc.js), and otherwise show a message that prompts the user to update the browser.

Is there any way to properly do this? More specifically, does the WebComponentsReady event guarantee 100% that Polymer has all it needs to work?

[pensierinmusica]

Btw @ebidel I've checked your code example in #26 (comment), it seems like 'import' in document.createElement('link') is false in Safari (v 9.0.1) and Firefox (v. 35) even after importing webcomponentsjs. Any idea how this could be fixed? Thanks!

[ebidel]

Is there any way to properly do this? More specifically, does the WebComponentsReady event guarantee 100% that Polymer has all it needs to work?

WebComponentsReady is only a signal that the polyfills are done and all elements/imports are loaded and ready to go.

Knowing if the browsers supports Polymer is trickier b/c the poylfills get you support in evergreen browsers. The best might be to look at this table: https://www.polymer-project.org/1.0/resources/compatibility.html

Not sure, but the HTML imports polyfill probably doesn't add .import to HTMLLinkElement. It populates it after the import is fetched though.

[pensierinmusica]

Not sure, but the HTML imports polyfill probably doesn't add .import to HTMLLinkElement. It populates it after the import is fetched though.

@ebidel, ok, this is the code snippet you mentioned above to check Web Components browser support:

var webComponentsSupported = (
      'registerElement' in document &&
      'import' in document.createElement('link') &&
      'content' in document.createElement('template'));

Do you (or anyone in this thread) have any suggestion on how to modify its import part so that it's reliable both in case of native support and polyfill with webcomponentsjs?

'import' in document.createElement('link')
// currently evaluates "true" for native, but "false" for polyfill

Thanks!

[ebidel]

You could try HTMLImports.useNative. If you're loading the polyfills though, I don't know why you'd need to re-check if imports are supported.

[pensierinmusica]

@ebidel, because I have no other convenient way to know if the current user's browser supports Web Components, even using polyfills. Imagine the user is browsing with Opera Mini, or IE9: the polyfill would not work properly. Am I getting this right, or missing something?

Even better, Polymer itself should provide a native method to do this check, after scripts have been parsed. In fact, we have no way to preventively know if the user browser offers native support or polyfills with webcomponentsjs.

[ckortekaas]

@pensierinmusica I'm not sure if you saw my earlier comments from June linking to our examples of browser support detection. We deliver Polymer based solutions to a large university where many students (and staff) have older devices (iPad 1/2's... yep...) and sometimes are trapped in older browsers due to their IT support SOE.

So we had to provide an elegant, graceful fallback for legacy devices and browsers. Instead of just a white screen of.. nothing.

To do this we essentially check each operating system version (iOS/Windows/OSX/etc) and then each browser version and correspond that with the minimum polyfill-able version of each. If the version (eg of iOS/safari) is below the minimum version (eg iOS 6 https://github.com/uqlibrary/uqlibrary-elements/blob/master/resources/common/preloader.js#L96) we give them a tailored message and encouragement to upgrade their browser. In addition even for browsers that CAN be polyfilled we use a browserupdate.org banner/js that encourages people to upgrade to more compliant browsers, but doesn't pester them too much (it knows if it's been dismissed).

We had hoped such detection and option to provide a tailored message would become part of Polymer 1.0+, but really it's not that hard to just implement yourself (use our example! it's MIT licenced!).

Safari, Firefox and even MS Edge seem to be finally heading towards a 2016 adoption of web components standards so eventually (2018?) we can remove our preloader.js checks.

[pensierinmusica]

Hi @ckortekaas, I agree with you that Polymer should definitely provide a native method for this!

In the meantime, why don't you publish your custom utility as a bower module and on https://customelements.io/?

Btw, on a quick look it seems like your library would suffer the same bug described here: #26 (comment)

Any idea how to fix it?

Cheers!

[ebidel]

@pensierinmusica this is not really how poylfills work, right? They attempt patch a missing feature in the browser. If for some reason that fails, you're out of luck. Are there example polyfills that report failures when they "don't work"?

Generally, it's very challenging to provide one API call that reports if the browser does or does not support all the things each polyfill (and polymer) does. For example, IE10 doesn't support pointer-events: none and has flaky Mutation Observers. That doesn't mean the polyfills should report IE10 is not supported. We provide the compatibility table as a guide to these types of idiosyncrasies. Ultimately, you should be looking at things like Analytics to determine which browsers to support; making decisions based on that.

FWIW, we ended up doing very similar things to @ckortekaas in the I/O site and Santa Tracker. We blacklisted browsers which are known to have certain issues.

One other things you can do, at least to know if native APIs are being used:

HTMLImports.useNative && CustomElements.useNative && Polymer.Settings.useNativeShadow

[pensierinmusica]

@ebidel, thanks for the feedback.

Imho a good polyfill should let the programmer know when it fails to provide the needed functionality. If we want to bring browser development to the next level (e.g. with projects like Polymer), front-end reliability must follow. A good starting point would be at least to have manifest failures, instead of silent ones.

On the other hand, you have a much wider experience than me on these topics, and surely can appreciate more in detail the implementation complexity. From this thread it looks like I'm not the only one with this need, it would be awesome if the Polymer or webcomponentsjs team could do something about it! Cheers

[indolering]

Move to close, no polyfill does this and there are no good tests one can run to see if it works or not. The only browsers that aren't supported are EOL, literally versions of IE and Safari that can't be updated because the OS support isn't there.

[TimvdLippe]

This is quite an old issue. With the webcomponents loader, this issue should no longer be prevalent (provided for the supported browsers). We leave any possible message up to the user to define how they want to signal to their users if there would be any issue loading.