AccessKit Disable GIFs: Feature doesn't override Tumblr's GIF pausing

[marcustyphoon]

Platform

macOS 14 arm64

Browser

Edge 148.0.3967.54

Addon version

v1.3.2

Details

Tumblr has a new feature where, if you have "reduce motion" or the equivalent enabled in your operating system settings and you're using a web browser that exposes this property to web pages, it pauses GIFs until you click on them. edit: This can now be toggled in tumblr settings; see post below.

AccessKit's Disable GIFs feature currently isn't aware of this, so the Tumblr feature and the XKit feature overlap: images will appear paused with the AccessKit Disable GIFs label, and then when you mouse over them they'll still be paused and have the Tumblr-native GIF label. Once you click, Tumblr makes them animated and AccessKit Disable GIFs pause-on-hover works as expected after that.

I think that ideally we would make AccessKit Disable GIFs replace the Tumblr version of the feature with its own when it's enabled. As noted in #2243, though, this is difficult because Tumblr now swaps out the animated and non-animated versions using javascript rather than having them both accessible so we can easily choose which one to display ourselves. As a less sophisticated implementation, we could potentially have AccessKit Disable GIFs just click the paused image, but I don't love that because it's not reversible, and we do try to make the off switches for our features fully functional.

I have to acknowledge that one could make the argument that, as Tumblr has now duplicated one of our features, we should simply remove our version. If the Tumblr version was a toggle in the Tumblr settings, I could see this argument (and I would then point out that I disagree with it; unpause-on-hover is what users want). However, because the current version of the Tumblr feature is triggered by doing something that a) nobody knows about, b) has side effects nobody wants, but most importantly c) literally doesn't work in some browsers, I think this argument is pretty dead on arrival.

[marcustyphoon]

@impetus82 Oh hello! Is this an AI agent searching across github for PRs with the "help wanted" label that are likely solvable? That was my guess based on looking at the set of comments made by your account, but I can't be sure.

[marcustyphoon]

Update: Tumblr has made this an actual setting, in https://www.tumblr.com/settings/dashboard! It's called "Media auto-play" and defaults to "Use system setting" (which I personally still think is the confusing one).

This is good, since it means users who actually want Tumblr's version can select "Never auto-play" there. I don't think we need to worry about those people (if they manually enable both features, and they get both features stacked on top of each other, things are arguably working as intended even if that's probably not what they want). If— oh, hang on... the Tumblr setting will also apply to videos.

Er, let me start over. This is good, since it means users who want Tumblr's autoplay disabled for all media can select "Never auto-play" there. Regardless of what that setting is, and whether or not the user is getting that setting intentionally or through the "system setting" passthrough from having reduce motion enabled in their operating system, it seems clear to me that a user who enables our Disable GIFs setting wants ours, not Tumblr's.

So yep: I think we should override Tumblr's version with ours (e.g. by simulating a click).

[marcustyphoon]

gifElement.parentElement.querySelector(keyToCss('playButton'))?.click();

Seems pretty simple (for always doing eager mode). Not sure if there are any annoying race conditions that would make us need to do a mutation observer here. Maybe I'll just run this for a bit and see if it breaks. edit: Never mind, it does break; darn.

Implementing lazy mode as well isn't too bad either... but making the lifecycle work correctly is a little weird. Might need an AbortController that gets fired during clean() to cancel a mouseenter listener.

edit: Aw, it's not really a mouseenter, actually, because of our hover containers. Meh. So I guess a proper implementation of lazy mode either requires putting mouseenter handlers on hover containers (not very DRY if we're using css hover detection normally), or... possibly a cool but convoluted method keeping the pure CSS hover detection behavior, having that rule set the display property, and detecting the change in display property with an intersection observer so js behavior can be coded off of css rules (okay, no, this second one is obviously way worse).