FastClick - too many issues

[Karl Dubost]

Hello everyone,

FastClick has been a webcompat hurdle for a long time.

https://miketaylr.com/posts/2017/10/fast-click-more-like-thing-of-the-past-click.html

Is there anything we could/should do either on the side of Gecko or Site Interventions to just kill it?

And having to avoid to have this accumulation of bugs for a long time.
https://github.com/webcompat/web-bugs/labels/type-fastclick


--
Karl Dubost, mozilla 💡 Webcompat
http://www.la-grange.net/karl/moz

[Mike Taylor]

Hi Karl,

On 6/28/20 9:32 PM, Karl Dubost wrote:
> Hello everyone,
>
> FastClick has been a webcompat hurdle for a long time.
>
> https://miketaylr.com/posts/2017/10/fast-click-more-like-thing-of-the-past-click.html
>
> Is there anything we could/should do either on the side of Gecko or Site Interventions to just kill it?

Should to me seems like an obvious yes. I'm not 100% on the "could" --
has anyone on the team done the work to explore a mostly functional shim?

A few questions I have:

Is FastClick typically loading via a predictable CDN? Or minified and
included in a site bundle?

Do we think we can efficiently disable it globally? Or by adding
`needsclick` classes to the DOM?
https://github.com/ftlabs/fastclick#ignore-certain-elements-with-needsclick

Are these issues due to an older version of Fastclick, or is the most up
to date version also problematic?

Can we inject a meta-viewport early enough so it bails?
https://github.com/ftlabs/fastclick/blob/master/lib/fastclick.js#L796-L806

--
Mike Taylor
Web Compat, Mozilla

[Thomas Wisniewski]

Note that we could also just support touch-action (or pretend to?):
https://github.com/ftlabs/fastclick/blob/master/lib/fastclick.js#L810

So maybe the better fix here is to just try to finish
https://bugzilla.mozilla.org/show_bug.cgi?id=1285685

> _______________________________________________
> compatibility mailing list
> compat...@lists.mozilla.org
> https://lists.mozilla.org/listinfo/compatibility
>

[Thomas Wisniewski]

This is interesting:
https://github.com/ftlabs/fastclick/blob/master/lib/fastclick.js#L810

Maybe the better fix here is to figure out if we can't just set
style.touchAction to "none" or "manipulation" by default, instead of an
empty string?

[Mike Taylor]

On 6/29/20 12:38 PM, Thomas Wisniewski wrote:
> This is interesting:
> https://github.com/ftlabs/fastclick/blob/master/lib/fastclick.js#L810
>
> Maybe the better fix here is to figure out if we can't just set
> style.touchAction to "none" or "manipulation" by default, instead of an
> empty string?

I think there may be implications to sites if we change the default
Gecko behavior, for example, from [1]:

> A declaration of touch-action: none; may inhibit operating a
browser's zooming capabilities.

[1] https://developer.mozilla.org/en-US/docs/Web/CSS/touch-action

Are you suggesting we hack this at the intervention level (that seems
less risky)?

[Thomas Wisniewski]

Yeah, looking at this a bit more, it seems like they're just testing if the
element the page is passing to fastClick has a .style.touchAction set, so a
low-level hack isn't likely going to be easy or a good idea. But we could
potentially add `.style.touchAction="none|manipulation"` to that element
before the page loads, on a site-by-site basis, at least (if that's better
than just using a UA hack).

I think the only way to really hack this on a Gecko level would be to watch
for window.FastClick to be set in the JS engine, so we override it with an
empty object or shim. Which I can't imagine would be considered acceptable
(plus I seem to recall that some sites bundle FastClick so that it does not
end up being set on the window object and may end up with another,
minified, variable name).

Maybe it would actually be better to just address the ultimate issue that
FastClick causes, which I believe was that select elements needed to be
tapped twice. If that's the case, it looks like FastClick is actually
working around that for Chrome, which would make this their bug:
https://github.com/ftlabs/fastclick/blob/master/lib/fastclick.js#L313

If that's indeed the culprit, I wonder if it would cause worse webcompat
issues to just allow click to open selects?

[Karl Dubost]

Le 1 juil. 2020 à 07:06, Thomas Wisniewski <twisn...@mozilla.com> a écrit :

> But it gets more complicated for code which is webpacked or otherwise bundled by a site, especially when they don't set window.FastClick, but place it on some other variable (and maybe even end up calling it some minified variable rather than FastClick).

Thanks for the context!
Probably we can try to address the majority of cases.
It would be interesting to go through all the previous cases and see what/how it is used.

[Thomas Wisniewski]

Agreed. If we know any specific URLs that sites are loading their script
from, then we can at least override them with the shim feature I'm adding
to the compat addon right now. But beyond that, we will have to think of
other means.

On Tue, Jun 30, 2020 at 3:06 PM Thomas Wisniewski <twisn...@mozilla.com>
wrote:

> > Wild thought, would site break if the full fastClick code was replaced
> by a placebo?
>
> Technically no, unless I'm missing something subtle. That's why we can
> just work around it so that their "not needed" code returns true. But the
> problem is finding a way to (efficiently) detect their code, and not run
> it. For instance, if Gecko could detect window.FastClick being set to a
> value, at which point we could change it to a shim of our own which does
> nothing (a placebo). So we could shim the cases where it's loaded by a
> script tag loading a known URL (from a CDN, for instance). But it gets more

> complicated for code which is webpacked or otherwise bundled by a site,
> especially when they don't set window.FastClick, but place it on some other
> variable (and maybe even end up calling it some minified variable rather
> than FastClick).
>

> On Tue, Jun 30, 2020 at 2:48 PM Karl Dubost <kdu...@mozilla.com> wrote:
>
>>
>>
>> Le 1 juil. 2020 à 02:25, Thomas Wisniewski <twisn...@mozilla.com> a
>> écrit :

>> > looks like FastClick is actually working around that for Chrome, which
>> would make this their bug:
>> https://github.com/ftlabs/fastclick/blob/master/lib/fastclick.js#L313
>>

>> Their bug for the future usage.
>> But Fastclick is most of the time legacy code which is not updated and is
>> not needed anymore on any sites, because browsers now handle what they were
>> trying to fix.
>>
>> Wild thought, would site break if the full fastClick code was replaced
>> by a placebo?

[Karl Dubost]

[Thomas Wisniewski]

> Wild thought, would site break if the full fastClick code was replaced
by a placebo?

Technically no, unless I'm missing something subtle. That's why we can just
work around it so that their "not needed" code returns true. But the
problem is finding a way to (efficiently) detect their code, and not run
it. For instance, if Gecko could detect window.FastClick being set to a
value, at which point we could change it to a shim of our own which does
nothing (a placebo). So we could shim the cases where it's loaded by a
script tag loading a known URL (from a CDN, for instance). But it gets more
complicated for code which is webpacked or otherwise bundled by a site,
especially when they don't set window.FastClick, but place it on some other
variable (and maybe even end up calling it some minified variable rather
than FastClick).

On Tue, Jun 30, 2020 at 2:48 PM Karl Dubost <kdu...@mozilla.com> wrote:

>
>