[Request] Fire synthetic events on page load, for extra site compatibility

[ghost]

This is a feature request and bug fix in one.

Some pages will initially load, but will wait before critical operations like laying out the page or loading assets, until the page is visible. For these pages we need to allow the visibility API and friends to pass, and this continues for the entire lifetime of the page - but we only really needed that one event, to kick things off.

If this addon fired a single synthetic event of each type it would later block, once the page is loaded, then we could keep a lot more sites blocked.

This also helps in general, to avoid a failure mode, where for example the site thinks the page is visible, since document.visibilityState == true, but never learns it is visible because no visibilityChange event was ever received, so there's this element that can logically be both 'visible' and 'not visible' at the same time, or neither visible nor invisible, according to entirely legitimate code. (this exact scenario broke the very popular Dark Reader addon (they provided a workaround at their end, to not check visibility))

Although it's always nice, I'm not even sure this needs to be optional. Firstly, it's fixing a bug, but secondly; At the moment, we gain privacy by giving no data on page visibility via events, and false data via variables, but I'd say there's even greater privacy in providing false data on page visibility via events, as well.

[brian-girko]

As far as I know, there is no special event to fire. Some websites do use "Window.requestAnimationFrame()" to delay some operations to the first available frame painting. The latest release supports bypassing this function. So if you find a website that still delays some operations until the page is visible let me know.

but never learns it is visible because no visibilityChange event was ever received

If a page is active, according to the specs, no visibility event is fired.

[ghost]

As far as I know, there is no special event to fire. If a page is active, according to the specs, no visibility event is fired.

When I was working on that Dark Reader issue, I saw FF firing visibilitychange and focus events, when switching to the tab. I'm pretty sure FF always does this, but I'm far from an expert. I'm far enough from an expert that I had to look up the spec, and it seems like it's meant to fire whenever the page becomes visible to the user. Am I reading the right thing here? https://w3c.github.io/page-visibility/#reacting-to-visibilitychange

if you find a website that still delays some operations until the page is visible let me know.

Dark Reader has a workaround now but it has performance implications so it's off by default and lightly buried in the settings. Any Dark Reader user who doesn't know to turn that on, is going to see their pages 'broken' by installing this addon.

There are a couple others which come to mind (most notably youtube) but maybe the changes for 0.19 will fix them, I'll test it when it is out :)

[ghost]

New version with animationframe spoofing seems to fool almost everything, so that's nice.

It still breaks Dark Reader, and will do the same to anything else which responds to the visibility event before checking the visibility property, as the spec suggests.

It's also occurred to me that this design creates a fingerprinting/detection vector. The page needs only to check for a mismatch between the visibility property and event, and it knows we are running this addon - That mismatch won't happen in normal conditions with any browser since they all perform the spec's 'now visible algorithm' which the spec says "MUST" (their capslock) be done. Reading through here I can't see any facility for the property to return 'visible' before an event is fired. I can't find (sorry, search engine problems) the initialisation value for visibilitystate, so if it initialises to visible, that would be the only logic that I can see where we could have it return visible before a visibilitychange event.

Am I missing something here? I feel like you'd rather avoid it but I don't understand why.

[ghost]

It still breaks Dark Reader, will do the same to anything else which responds to the visibility event before checking the visibility property, as the spec suggests.

Vuetify apps are doing this.

I've had to uninstall this because I need these sites working :(

[ghost]

Done in https://github.com/brian-girko/always-active/commit/84142b9315620f73b14b4b90bf5d065834af3172