Back-forward cache: Restoring focus

[rakina]

It looks like focus works differently with bfcache in Safari, Firefox, and Chrome (thanks @tkent-google for noticing!)

If we navigate away from a page that has a focused element (e.g. submitting a text-input form), and we go back & restore it from bfcache (tester page) :

• Safari: The focused element stays focused. The blur event is never fired. The focus event is only fired when the element initially gets focused.
• Firefox: The focused element stays focused. The blur event is fired after pagehide (when navigating away) but before pageshow (when navigating back). The focus event is fired for the second time after pageshow.
• Chrome: The focused element will lose focus on navigation away from the page (with the blur event fired before pagehide), and won't be focused again when we navigate back.

I think it would be ideal to restore the focused element when navigating back (like Safari & Firefox is currently doing), but I'm not sure whether it should be "focus is kept all this time" (so no blur event should be fired), or "focus was lost, but it's back again" (so we fire blur when navigating away, then fire focus when navigating back). Maybe the latter makes more sense as the entire document/page is no longer in focus after we navigate away from it.

[annevk]

cc @cdumez @smaug----

[domenic]

I don't have much of substance to add, but I will say that this seems like a nice and small interop bug we could fix, compared to all the other scary bfcache business :). I hope we can get implementers to chime in.

I'm ambivalent myself between "focus is kept all the time" vs. "focus was lost, but it's back again". Maybe there are other similar features affected by bfcache which we could compare with?

[domenic]

Slightly related: WICG/portals#257

[domenic]

Various folks discussed this today in the triage meeting (#6371). The Mozilla and Google representatives present thought that between the Firefox and Safari behavior, the Safari was probably best. Although nobody felt too strongly, the idea of firing less events (and thus running less script) during page unload and load pushed us in that direction.

This might be what the spec already says; in particular I can't find anything that changes the focused area of the document, or runs focusing or unfocusing steps, on navigation (including bfcache navigation). However, it's possible the focus fixup rule applies upon navigations, if elements in navigated-away-from-documents are not "being rendered"... but I'm unsure. That might be worth investigating.

So, I think the action items here are:

1. Investigate "being rendered" for bfcached pages.
2. If elements in bfcache pages are "being rendered", i.e. if other parts of the spec ecosystem expect such elements to have CSS boxes etc., then:
   1. Add a clarifying non-normative note to the definition of "being rendered" explaining that even inactive documents can have being-rendered elements.
3. If elements in bfcache pages are not "being rendered", then:
   1. Add a clarifying non-normative note to the definition of "being rendered" explaining this.
   2. Update the normative text of focus fixup rule to not run for when documents become inactive? Or some other normative fix, like changing the "being rendered" clause in the definition of focusable area.
4. Add a clarifying non-normative note to "focused area of the document" explaining that this does not change when a document becomes inactive or becomes active again.
5. Write web platform tests.
6. File browser bugs on Firefox and Chrome.
7. Fix browser bugs :)

[rakina]

Thanks @domenic! I looked into "being rendered" & "fully active" a while back, and found that "being rendered" is still true for non-fully active documents. I've sent a PR at #6696 to add notes as you suggested, and @hiroshige-g will upload a WPT PR soon!