Hm... looks like we're firing pagehide during page navigations bugs not visibilitychange as far as I've audited the code.

@rniwa yes, that sounds inline with the results I was seeing in my testing. If I recall correctly, pagehide was being fired when navigating as well as when closing a tab on desktop Safari (here's another test page that logs more than just the visibilitychange event).

I don't think pagehide was being fired when closing Safari from the App Switcher, but I think that's acceptable if visibilitychange can be fired when entering the App/Tab Switcher on mobile operating systems (which this issue is proposing).

We discussed this issue on today's WebPerf WG call, and the consensus was to update the Page Visibility spec to clarify that the hidden visibility state should include cases where the tab may be visible (e.g. a preview/screenshot) but it's not fully interactive to the user.

This includes cases such as:

• A preview/screenshot of the page is shown when a user enters the App Switcher or Tab Switcher on mobile devices
• A desktop browser introduces a new tab-selection interface that displays a screenshot of each tab open in the current window

In the cases above, despite the fact that a view of the page is visible to the user, these pages are still considered to be in the hidden state because they are not fully in the foreground or interactive to the user (without refocusing).

After making a change to the spec, UAs should update their app/tab-switching logic to fire the visibilitychange event as soon as the user enters the App Switcher or Tab Switcher (today the event is only fired once the user selects a new tab/app to switch to.

@bdekoz does this seem reasonable to you? No one from Mozilla was on the call today, and given that Firefox is the only browser to currently fire visibilitychange in all these cases I tested, I wanted to check and ensure you'd be OK with making such a change.

@bdekoz - friendly ping! :)

I wonder if there something we can hook into from HTML about the document becoming inactive (or no longer user interactive)? @domenic, can you suggest if there is anything that is similar to what is described in #59 (comment) in HTML? (related also to #51 (comment))

Not really. The closest would be the not-well-defined notions of "window having focus". See whatwg/html#5493 for the latest time that came up, which also has pointers to previous bugs. /cc @mustaqahmed.

However I suspect that trying to reuse "window focus" would not give the results you want on desktop browsers, so perhaps this is just an entirely new concept.

after thinking about this a bit, in addition to phillipwalton's jan 30 comment, the case where

• a preview/screenshot is shown in a tab switcher or app switcher
• any new tab-selection interface

are cases where there is no top-level browsing context (as per july 30, 2020 meeting). If it would clarify visibility wording, this could be explicitly noted, saying it is a top-level internal context or top-level navigation context and not a top-level browsing context? Or some other terminology TBD in https://html.spec.whatwg.org/multipage/browsers.html#top-level-browsing-context

With this or similar clarification, it does seem reasonable for behavior where entering the tab switcher means other pages (even pages that have been active and have screenshots) are marked hidden

@bdekoz - re-reading the definition of top-level browsing context, it doesn't seem like being backgrounded changes it.
Rendering opportunity does take backgrounding into account, but doesn't properly define it.

One thing we can do is to expand determine the visibility state in order to also take into account backgrounding, and properly word it so that a page-preview doesn't count as "visible".

I'm not sure what's being proposed is the right behavior. If you start playing a video on youtube.com on Safari and open app switcher, for example, the video will continue to play. Things like animations, etc... will need to continue to work in this state up until the user switches to another app.

Interesting! Maybe we need some third state (e.g. "preview") where the page would know it might soon be terminated, but needs to continue to display its content?

Maybe what we need is something like "noninteractive", a state to indicate that the page is visible but not currently being interacted / interactive with the user.

Yeah. Added this as a discussion topic for this week's WG call.

Safari has fixed visibilitychange on navigations: https://bugs.webkit.org/show_bug.cgi?id=151234. (I am unable to validate on device)

However, I also tried to re-run the steps from Philips initial post and noticed a few new peculiarities:

• On Chrome, I am beginning to think there probably is correctly a visibilitychange: hidden event fired every time App switcher is launched, regardless if Chrome is later closed or re-focussed. However, I think maybe there may actually be a problem with saving to localStorage, causing a bug in the test itself. I will try to validate using an alternative method (like sending a beacon/XHR).

• In Firefox on Android, when launching app switcher and killing FF, indeed you correctly get a visibilitychange: hidden.. but it seems you also get a spurious visibilitychange: visible as well (without a final visibilitychange: hidden). (Speculation: FF is giving JS within tab contents time to unload, but this also unintentionally(?) gives visibility?)

(...for reproducing the FF spurious visibility:hidden, I was actually using the more detailed test page with the beforeunload handler registered. I haven't been able to reproduce again.)

I will say: even in FF, the visibilitychange: hidden event does not always arrive on app close.

Adding my 2c, it seems undesirable to conflate visibility with a "you might get terminated" signal, the app switcher example is pretty clear why.

A non-interactive state seems to avoid this case but I worry that

• it still conflates the termination signal with an unrelated app state (if some new exotic state is invented in the future we're back to the same problem)
• intuitively, a non-interactive state cover basically every state other than "foreground tab" which makes it less useful in other scenarios

Some examples of things we'd want to do in prerendering/portal-type contexts:

• Avoid recording analytics until page is made active
• Mark a user as "away" in a chat app
• Avoid starting a transaction countdown timer on a concert ticketing page until active

If we include background tab in "non-interactive" as would be intuitive it couldn't be used in any of these cases and would require an additional state.

Has anyone explored adding an explicit event for the "you may be terminated without further notice" situation? It sounds like the failure of unload events is that they promise more than the browser can deliver. Such a lastchance event could be worded and fired anytime the page might not get another chance to run: at unload but also at mobile background tab, app switcher, etc.

FYI: I've expanded on the above in #69 - would appreciate any feedback there. In particular @bdekoz and @rniwa as this relates to preview-like situations which the app switcher examples above fall into.

I suggest to move this discussion to the HTML spec