1568934 - don't accept clicks immediately after a page shifts

Status: UNCONFIRMED

(Core :: DOM: Events, enhancement)

Description

[Darxus]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

Often, as a page is loading, links move around. So sometimes, when I try to click on something, it moves just before I click on it, and I end up accidentally clicking on something else. It would be nice if firefox ignored those clicks. Bonus if it provides some kind of visible or audible clue that it was ignored.

Inspired by this person with a similar frustration: https://www.reddit.com/r/Lightbulb/comments/chqrpi/no_superhuman_clicks_mode/

Comment 1

[Marcela (Please NI request to Brindusa Tot)]

I have changed Product and Component, please feel free to modify it if it is necessary.

Comment 2

[Daniel Holbert [:dholbert]]

(In reply to Darxus from comment #0)

Sometimes, when I try to click on something, it moves just before I click on it, and I end up accidentally clicking on something else. It would be nice if firefox ignored those clicks. Bonus if it provides some kind of visible or audible clue that it was ignored.

[late response, sorry!]
I'm dropping some thoughts here, since this problem-space came up in a related bug.

This sort of thing can definitely be frustrating, but it's definitely not as simple as "don't accept clicks immediately after a page shifts" as suggested by the bug title here. There are tons of legitimate scenarios that would be broken by such an intervention. Basically any sort of dynamically moving content could be broken (in the sense of rejecting clicks that the user may in fact want or need to be accepted) -- e.g.:

• photo carousels (e.g. clicking an image as it slides on-screen in a carousel widget, or clicking elsewhere and wanting those clicks to be honored while that widget is continuously shifting/scrolling)
• video control UI (whether browser-native or web content) where a "thumb" is dynamically moving (perhaps rapidly) across the video-progress track to represent progress in the video. [Depending on how you define "a page shifts", you might imagine this being included as something that would inadvertently cause clicks to be suppressed.]
• games with clickable targets moving across the screen (or with the browser dynamically scrolling across static clickable targets)
• Chat apps like slack etc. with content continuously appearing and scrolling up the page. (When a new message appears and moves content in the chat-backscroll, that shouldn't make the browser prevent you from clicking the site's "settings" button, for example.)
• simple cases with documents like what you described, where something moves, but only by a little bit, or in a way that doesn't impact your click-target. (In these cases, you could imagine us blocking your click "just in case" but it could be frustrating if you did actually click the right thing.)

There are two mitigations that exist that help here, though:
(1) Scroll Anchoring: https://drafts.csswg.org/css-scroll-anchoring/#intro -- this typically prevents dynamically-loading or resizing offscreen content from pushing content out from under your cursor. (e.g. if you load a page and scroll down, and then a header-image loads and pushes content down, the browser will adjust your scroll position so that you don't notice the layout change)

(2) The web development best-practice of minimizing & avoiding "Layout Shift" / "Cumulative Layout Shift" in general. I think Google search is actually measuring this metric when indexing pages, and using it as a small factor when rank-ordering site in search results, to incentivize sites to be better about this. See https://web.dev/optimize-cls/ and other resources on that.