Bring back support for prerendering page state

[bokand]

Hi all!

Following up on the TPAC meetup about bringing back prerendering to the web platform. I'd like propose a way to (re-)expose prerendering state to the page.

I've compiled some research and thought on existing uses of visibilityState and related issues and drew some conclusions and maybe a path forward.

Would appreciate any feedback/thoughts/opinions.

To summarize some of the background:

• Don't bring back visibilityState: 'prerender'
  • Pages often use visibilityState != 'visible' ==> 'hidden'
  • Prerendering may be more nuanced, e.g. portals are prerendering but visible
  • Use cases for this state aren't related to visibility but to intent/persistence/interaction
    • e.g. Should the page record analytics?
    • e.g. Should the page connect to a live-chat server
• visibilityState is already overloaded, it's used as a "could be disposed" signal
  • Causes browsers to sometimes lie (e.g. mobile app switchers, see The spec's definition of hidden is unclear and should be updated to better account for mobile use cases #59).
  • Adding prerendering/portals as visibility makes this more complicated.

Proposal

• Add a new document.prerendering flag (and associated change event)

  • Use this to tell the page that's it's loaded in a context that's not necessarily intentional or interactive.
  • This would be true of a typical prerender or portal.
  • It could also be true for app/tab switcher type scenarios or future "overview" type modes where sites are live but not interactive.

• Add a becameDisposable event

  • Somewhat tangential to prerendering but related to visibility
  • Want to make visibilityState return the true visibility status of a page. This is difficult if it's also an unload signal for the page (see The spec's definition of hidden is unclear and should be updated to better account for mobile use cases #59).
  • Fire in all cases where it may be the last opportunity to save/communicate state
    • e.g. entering background on mobile
    • e.g. entering the mobile app switcher
    • e.g. (maybe) foreground page is adopted into a portal
  • Pages using visibilityState for this today would continue to work in most cases but could gradually adapt to better handle edge cases like the app switcher.
  • This could also allow future optimization (e.g. firing it from an OS provided willKillProc callback rather than immediately on backgrounding).

Thanks!

[bokand]

FYI: discussed this in the Dec 3 call

It was mentioned that, specifically for analytics, tools might want to know about previous state of prerendering. This is similar to #29 for visibilityState.

It sounded during the call like @nicjansma might have some insight in this area :)

Nic: Do you know of any specific use cases or what analytics packages might want to do with this information (or where I might look)?

#29 is distinctly about performance measurement which means they want it tied to PerformanceEntries - ideally that would be helpful for performance use cases generally and not just visibility. However, I'm wondering if there's anything specific for prerendering? If so, would a simple "did load in prerender" bit be enough.

[bokand]

I've got an explainer for a document.prerendering flag but at a summary this is a new state bit that returns 'true' if we're in a prerendering-like state (i.e. includes regular prerender or portal-type preview):

partial interface Document {
    readonly attribute boolean    prerendering;
    attribute EventHandler        onprerenderingchange;
};

It's too early to request anything resembling an official position from WebKit/Gecko but @rniwa @bdekoz - do you have any high level thoughts about this approach, or anything obviously objectionable from WebKit/Gecko's perspective? (Or could loop in the right people if that's not you?)

I'd like to start implementing this behind a flag for experiment so it'd be great to get some feedback early.

[noamr]

This is handled in https://wicg.github.io/nav-speculation/prerendering.html
Closing for now