Firefox 68 for Android does not polyfill pointer event about polyfiller

[wessberg]

Yeah, of course! The changes will be non-breaking at first in terms of the public API. There will be deprecations and a plan to migrate users to the new one over time.

[wessberg]

Hey there. I looked into the problem, which was caused by browserslist-generator treating Firefox on Android as equivalent to Firefox on Desktop since the Caniuse data that Polyfiller is relying on for the time being is better for desktop Firefox and there has been feature parity between the two variants of Firefox for some time. However, this has clearly changed, and thanks for making me aware of it. I've started to distinguish between the two and added a test to ensure that the feature detection returns false for the user agent.

I'll deploy a new version of Polyfiller as soon as possible and will close this issue when that happens.

[tommedema]

Ok thanks.

By the way wouldn’t it be much more reliable and future proof to do feature detection with JavaScript and then only load the poly fill of the feature doesn’t exist?

[wessberg]

Basing the feature detections and available Caniuse and mdn data, and generating a Browserslist from the user agent has proven to be somewhat unreliable and not granular enough. The thing is that I've completely rewritten Polyfiller over the past year with a much more advanced software infrastructure which includes actually deploying feature detections to thousands of browsers and building up a correct database of data. This is also why no real development is happening in this repo, because the entire thing is happening in a private repo, before I'll finally merge the two.

[tommedema]

@wessberg why so complicated?

can't you just use https://modernizr.com/ to load polyfills dynamically if a feature is not available?

[wessberg]

We only have the request headers to work with on the server-side. You are however correct that we could send back a list of feature detections to the client in the first response from Polyfiller, which the client could then execute before sending back a follow-up request, this time pre-qualified for a specific set of features that the feature detections didn't pass for. This, I assume, is what you are suggesting. The advantage of this approach is of course that we get 100% reliable data based on that specific client. The disadvantage, however, is that we need to have several network roundtrips, as well as added payload size: the first roundtrip with the feature detections (of which there may be hundreds), and the second roudtrip with whatever features is requested by Polyfiller after running the feature checks.

The new architecture has the advantages of both approaches! When it sees a new User Agent, it checks if it has run the feature detections for that specific user agent, and if so, it doesn't need to do that again and can just immediately send back a pre-built bundle sitting in the cache waiting to be sent back in an instant. However, if a user agent representing an unknown engine or for which we have no data is requesting data from Polyfiller, it instead sends back a bunch of feature detections, before finally generating a follow-up request to Polyfiller with the specific features needed. Polyfiller then puts that in the cache such that it knows how to treat that specific user agent in the future. To build up an initial seed, the feature detections are deployed to thousands of browsers in all sorts of environments such that for by far the most versions of browsers, we won't need two network roundtrips, because we already have the data. That's the new infrastructure, and it's going to be great!

[tommedema]

Sounds good. Since people are already using polyfiller in production, I hope we can make the migration go smooth (not have it fail on our users)

[wessberg]

Closed, given that a new version of Polyfiller has been deployed that contains this fix.