+++ This bug was initially created as a clone of Bug #1516963 +++

STR:

• Go to an instagram profile on Fennec, e.g: https://www.instagram.com/mozilla/
• Try to dismiss the "The best Instagram experience is on the app." banner.

Expected:

You can dismiss it.

Actual:

You can't easily dismiss the banner unless clicking it multiple times, or force zoom-in the page to make the X larger enough to click.

I fixed bug 1516963 which makes AccessibleCaret doesn't show when clicking on the X, but per bug 1516963 comment 12 the banner still cannot be dismissed easily.

This might somewhat be related to touch event handling or pan zoom. CC :kats and :botond.

Does it work better if you set ui.mouse.radius.enabled to true?

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #1)

Does it work better if you set ui.mouse.radius.enabled to true?

Yes! It does. I can dismiss the Instagram banner easily with ui.mouse.radius.enabled=true.

:snorp, any thoughts on re-enabling this pref? It's still the first thing I enable on any Gecko android browser since without it i find clicking on things basically impossible.

Yeah I think we should revisit this. IIRC, the reason we disabled it was that some hamburger menus were impossible to select. Did we fix that problem?

Randall, do you recall the exact details of why we disabled the touch radius stuff?

It's because it makes elements that are made clickable with js libraries like jquery become unclickable if there is a regular link object next to it. The touch radius always finds the regular link since the jquery link just looks like a div or such.

(In reply to Randall Barker [:rbarker] from comment #6)

It's because it makes elements that are made clickable with js libraries like jquery become unclickable if there is a regular link object next to it. The touch radius always finds the regular link since the jquery link just looks like a div or such.

Ah, and I think some frameworks always connect listeners to the document or something so we can't immediately see that there is a click handler. It's coming back now.

Yes,all the clicks/touches were being processed by the root so there wasn't an obvious way to know if a element was clickable. We thought about doing a two pass method where if the point failed to be processed, use the radius to test for a clickable element. But I could never get it to work.

FWIW I never run into this problem with the mouse radius enabled. But I'm constantly frustrated by not being able to tap on things with the mouse radius disabled.

(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #9)

FWIW I never run into this problem with the mouse radius enabled. But I'm constantly frustrated by not being able to tap on things with the mouse radius disabled.

I tested this in Chrome and the Instagram banner is also difficult to dismiss in Chrome. However, Fennec/Fenix makes it even more difficult because the "SELECT ALL" context menu opens when your tap misses the X button.

Bug 1437372 and bug 1465743 describe related difficult-to-click-button problems in Fennec.

Randall disabled ui.mouse.radius.enabled in bug 1247095 three years ago to unbreak multiple broken sites: bug 1192558, bug 1233272, and bug 1235339.

So it seems like this bug is at a standstill: fixing in makes some links unclickable, but not fixing it makes some links difficult-but-not-impossible to click.

Hi, I've retested this issue using the latest Nightly build (68.0a1 from the 6th of May) on a Google Pixel 3XL(Android 9)and the problem can still be replicated.
As per the attached video and by judging the cursor, the selection of the 'X' button has to be quite precise to be able to dismiss the banner.

Wouldn't this be more of an accessibility issue on Instagram's part? And so filing a bug with them, when resolved would fix the issue on all browsers?

QA reports a similar problem trying to tap the dismiss button on Vimeo.com's cookie banner:

https://github.com/mozilla-mobile/fenix/issues/4147

Since this popup banner is also difficult to close in Chrome, I asked our WebCompat team if we have contacts at Instagram:

https://mozilla.slack.com/archives/C4FMB0AJY/p1571862510021900

This has now been moved to Fenix's top priority queue.

(In reply to Emily Toop (:fluffyemily) from comment #16)

This has now been moved to Fenix's top priority queue.

I still think the right way forward here is to re-enable the pref by default, and then revise the code to exclude the mouse fluffing in additional scenarios. If we exclude it on elements with :hover CSS, that would resolve bug 1192558. If we exclude it from happening on long-press events, that would resolve bug 1233272. If we exclude it on pages with click listeners on the root html element, that should fix those jquery cases. At the very least we should be able to get the overall UX to a better state than it is now.

If nobody has objections to the above approach, I'm willing to take ownership of ensuring it gets disabled in whatever scenarios it's getting mis-applied in. Worst case we can always turn the pref back off later if we run into cases where it's too hard to resolve.

Thanks Kats. I think it would be great to enable the pref and exclude it under certain conditions.

Adding Fenix priority tag

Calling this fixed via bug 1618532. However when I try to repro with the STR in comment 0, the "use the app" banner doesn't have an "X" close button, instead it has a "not now" link that is easy to click on. So either I got A/B tested into a different variant of the banner or they changed their site. Either way this doesn't seem to be a problem any more, and with bug 1618532 in place it shouldn't be a problem if they change it back.