addons.mozilla.org - "Select a collection" drop-down list is not triggered

[sdgrs546547Q]

URL: https://addons.mozilla.org/es/firefox/addon/darkreader/

Browser / Version: Firefox Mobile 98.0 Operating System: Android 11 Tested Another Browser: Yes Chrome

Problem type: Site is not usable Description: Buttons or links not working Steps to Reproduce: I can't add an extension in Firefox Add-Ons to a collection in Firefox for Android, but I can on the same device but on Chrome

View the screenshot

Browser Configuration

• None

From webcompat.com with ❤️

[sdgrs546547Q]

Here is the MP4 that reproduces the issue. https://ibb.co/G5DSWy2 Thanks

[benyaminl]

Here is the MP4 that reproduces the issue. https://ibb.co/G5DSWy2 Thanks

sadly to add to collection, we must change it to desktop view

[softvision-oana-arbuzov]

Thanks for the report, I was able to reproduce the issue. "Select a collection" drop-down list is not triggered.

Note:

1. The issue does not occur on Chrome.
2. The issue does not occur on Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)

Tested with: Browser / Version: Firefox Nightly 98.0a1 (🦎 98.0a1-20220207065816) Operating System: Google Pixel 5 (Android 12) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density) Moving to Needsdiagnosis for further investigation.

[qa_06/2022]

[denschub]

Mh, I can't reproduce this on the same build, and I pinged @eviljeff and he can't either. There was no deployment to AMO since last Thursday, so this also wasn't fixed/regressed by accident just now. Weird.

@ksy36 or @karlcow, could you give this a try? I've also pinged Fenix folks, hoping that someone there can reproduce.

[diox]

As mentioned on Matrix, I can reproduce with 96.3.1 (Release) on Android 12. A few additional details:

• I can also reproduce on the language <select> in AMO's footer
• Neither of those <select> have particularly fancy CSS or JS attached AFAIK
• I can't reproduce in desktop mode
• I can't reproduce on other pages with <select> elements. I tried the one referenced in https://github.com/mozilla-mobile/fenix/issues/23394 and a couple other websites

[denschub]

Thanks for the details. I pinged the Fenix team internally as well, maybe someone there has an idea or can look into it.

[kbrosnan]

This looks like something @emilio may know about. There was breakage as part of https://bugzilla.mozilla.org/show_bug.cgi?id=1750395 Seems like something that should be in Bugzilla.

[karlcow]

This is probably expected.

webpack://mozilla-addons-frontend/node/node_modules/fastclick/lib/fastclick.js

The current page is not working on Firefox Mobile Android because of the FastClick library. They just need to remove it.

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

@diox Could we try this first?

[karlcow]

fwiw https://github.com/webcompat/web-bugs/labels/type-fastclick is a major source of breakage.

[eviljeff]

fwiw type-fastclick is a major source of breakage.

fastclick was added to addons-frontend in 2017 https://github.com/mozilla/addons/issues/10163 so it must be a recent change in gecko? Could be https://bugzilla.mozilla.org/show_bug.cgi?id=1750395 - though @diox said he could reproduce in 96 and 1750395 only landed in 98.

[diox]

mmm I thought we had removed fastclick, looks like we never did.

I agree we should try removing it, but as @eviljeff points out this seems to be a recent problem while we've been using fastclick since 2017. Also, back when it was added both the team and QA found it did improve things, despite the fact that it was already supposed to be obsolete at the time.

Edit: I filed https://github.com/mozilla/addons/issues/14343 on our end.

[emilio]

@kbrosnan this is not a problem on Nightly, right? The select element works fine here. https://bugzilla.mozilla.org/show_bug.cgi?id=1750395 which is what broke that temporarily landed for 98 so I doubt that caused it...

A regression range would be the most useful, I'll try to get to it later today if nobody does it sooner.

[emilio]

It works on release as well for me... Probably this was reported just when I broke on Nightly, and presumably it's fixed now?

emilio commented 2 years ago

But that is inconsistent with the comments above, so there's something I'm missing...

diox commented 2 years ago

This is definitely broken for me on Release. I can't say for certain it worked before (I never used the <select> on the site with my mobile before).

FWIW, I've experimented with removing fastclick locally and it does solve the problem for my device, so unless some problems are found with that we'll likely be removing it, but it may still be valuable to look into why I could reproduce and not others...

karlcow commented 2 years ago

It's broken for me on 99.0a1 Nightly from yesterday. grmph. And indeed fastclick is probably not the reason if it's in there since 2017. Grmph bis repetita.

emilio commented 2 years ago

Can someone that can reproduce this mozregression this? Hopefully it repros with gve.

ksy36 commented 2 years ago

This is reproducible in both release and Nightly for me on Pixel 4a, tried running mozregression and it is reproducible as far as 2021-02-09 (can't check further than that: TaskCluster only keeps builds for one year. Using 2021-02-09 12:49:46.823423 instead of 2020-01-01).

There are reports about this issue as far as Dec 3, 2020, see https://github.com/mozilla-mobile/fenix/issues/16399 and https://bugzilla.mozilla.org/show_bug.cgi?id=1681522

I think this is likely a fastclick issue that is affecting certain devices

ksy36 commented 2 years ago

A bit of debugging, from: https://github.com/ftlabs/fastclick/blob/main/lib/fastclick.js#L803

it looks like the following condition is used to determine whether fastclick is not needed:

// Chrome 32 and above with width=device-width or less don't need FastClick
if (chromeVersion > 31 && document.documentElement.scrollWidth <= window.outerWidth) {
     return true;
}

if (firefoxVersion >= 27) {
    // Firefox 27+ does not have tap delay if the content is not zoomable - https://bugzilla.mozilla.org/show_bug.cgi?id=922896

    metaViewport = document.querySelector('meta[name=viewport]');
    if (metaViewport && (metaViewport.content.indexOf('user-scalable=no') !== -1 || document.documentElement.scrollWidth <= window.outerWidth)) {
        return true;
    }
}

So the difference seems to be that in Chrome document.documentElement.scrollWidth <= window.outerWidth, but it's false in Firefox on my device (so fastclick is not enabled on Chrome, but enabled on Firefox in my case).

diox commented 2 years ago

I can confirm that. On my device right now (Pixel 3a with Android 12, Firefox 96.3.1), on AMO, I can see:

>>> document.documentElement.scrollWidth
396
>>> window.outerWidth
393

Content it not horizontally scrollable though - a vertical scrollbar is only shown if I initiate scrolling, and it doesn't not cause a reflow, it's painted on top of the document.

I've submitted a pull request to get rid of fastclick on AMO in https://github.com/mozilla/addons-frontend/pull/11136. As mentioned above it seems fine without, so I'll do more testing but we'll probably remove it next week.

The difference in behavior with Chrome is weird though - that fastclick logic seems to make sense at first glance...

karlcow commented 2 years ago

Super cool find @ksy36 !!! Thanks @diox

emilio commented 2 years ago

@diox / @ksy36, what is window.devicePixelRatio on your device? I wonder if this is related to https://bugzilla.mozilla.org/show_bug.cgi?id=712225

diox commented 2 years ago

>>> window.devicePixelRatio
2.727272727272727

ksy36 commented 2 years ago

Same here, it's 2.727272727272727

denschub commented 2 years ago

That's interesting! Both of my test endpoints that do not reproduce this issue (the emulator, and an actual device) have window.devicePixelRatio == 2.

diox commented 2 years ago

FWIW AMO has removed fastclick in https://github.com/mozilla/addons-frontend/pull/11136. When doing that, we did notice it caused a regression, https://github.com/mozilla/addons/issues/14344 that we had to find a workaround for. So despite causing an issue for some browsers on some devices, fastclick was useful in some capacity before. That being said, I'm very happy it's gone, one less thing to worry about in our stack.

karlcow commented 2 years ago

Thanks!

softvision-oana-arbuzov commented 2 years ago

I can also confirm it is working now, the drop-down menu is triggered.

Tested with: Browser / Version: Firefox Nightly 99.0a1 (🦎 99.0a1-20220303094735) Operating System: Google Pixel 5 (Android 12) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density), Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)

[inv_09/2022]

• © Githubissues.
• Githubissues is a development platform for aggregating issues.

[emilio]

But that is inconsistent with the comments above, so there's something I'm missing...

[diox]

This is definitely broken for me on Release. I can't say for certain it worked before (I never used the <select> on the site with my mobile before).

FWIW, I've experimented with removing fastclick locally and it does solve the problem for my device, so unless some problems are found with that we'll likely be removing it, but it may still be valuable to look into why I could reproduce and not others...

[karlcow]

It's broken for me on 99.0a1 Nightly from yesterday. grmph. And indeed fastclick is probably not the reason if it's in there since 2017. Grmph bis repetita.

[emilio]

Can someone that can reproduce this mozregression this? Hopefully it repros with gve.

[ksy36]

This is reproducible in both release and Nightly for me on Pixel 4a, tried running mozregression and it is reproducible as far as 2021-02-09 (can't check further than that: TaskCluster only keeps builds for one year. Using 2021-02-09 12:49:46.823423 instead of 2020-01-01).

There are reports about this issue as far as Dec 3, 2020, see https://github.com/mozilla-mobile/fenix/issues/16399 and https://bugzilla.mozilla.org/show_bug.cgi?id=1681522

I think this is likely a fastclick issue that is affecting certain devices

[ksy36]

A bit of debugging, from: https://github.com/ftlabs/fastclick/blob/main/lib/fastclick.js#L803

it looks like the following condition is used to determine whether fastclick is not needed:

// Chrome 32 and above with width=device-width or less don't need FastClick
if (chromeVersion > 31 && document.documentElement.scrollWidth <= window.outerWidth) {
     return true;
}

if (firefoxVersion >= 27) {
    // Firefox 27+ does not have tap delay if the content is not zoomable - https://bugzilla.mozilla.org/show_bug.cgi?id=922896

    metaViewport = document.querySelector('meta[name=viewport]');
    if (metaViewport && (metaViewport.content.indexOf('user-scalable=no') !== -1 || document.documentElement.scrollWidth <= window.outerWidth)) {
        return true;
    }
}

So the difference seems to be that in Chrome document.documentElement.scrollWidth <= window.outerWidth, but it's false in Firefox on my device (so fastclick is not enabled on Chrome, but enabled on Firefox in my case).

[diox]

I can confirm that. On my device right now (Pixel 3a with Android 12, Firefox 96.3.1), on AMO, I can see:

>>> document.documentElement.scrollWidth
396
>>> window.outerWidth
393

Content it not horizontally scrollable though - a vertical scrollbar is only shown if I initiate scrolling, and it doesn't not cause a reflow, it's painted on top of the document.

I've submitted a pull request to get rid of fastclick on AMO in https://github.com/mozilla/addons-frontend/pull/11136. As mentioned above it seems fine without, so I'll do more testing but we'll probably remove it next week.

The difference in behavior with Chrome is weird though - that fastclick logic seems to make sense at first glance...

[karlcow]

Super cool find @ksy36 !!! Thanks @diox

[emilio]

@diox / @ksy36, what is window.devicePixelRatio on your device? I wonder if this is related to https://bugzilla.mozilla.org/show_bug.cgi?id=712225

[diox]

>>> window.devicePixelRatio
2.727272727272727

[ksy36]

Same here, it's 2.727272727272727

[denschub]

That's interesting! Both of my test endpoints that do not reproduce this issue (the emulator, and an actual device) have window.devicePixelRatio == 2.

[diox]

FWIW AMO has removed fastclick in https://github.com/mozilla/addons-frontend/pull/11136. When doing that, we did notice it caused a regression, https://github.com/mozilla/addons/issues/14344 that we had to find a workaround for. So despite causing an issue for some browsers on some devices, fastclick was useful in some capacity before. That being said, I'm very happy it's gone, one less thing to worry about in our stack.

[karlcow]

Thanks!

[softvision-oana-arbuzov]

I can also confirm it is working now, the drop-down menu is triggered.

Tested with: Browser / Version: Firefox Nightly 99.0a1 (🦎 99.0a1-20220303094735) Operating System: Google Pixel 5 (Android 12) - 1080 x 2340 pixels, 19.5:9 ratio (~432 ppi density), Samsung Galaxy S8 (Android 9) - 1440 x 2960 pixels, 18.5:9 ratio (~570 ppi density)

[inv_09/2022]