Handling of focus inside a portal

domenic commented 4 years ago

@a4sriniv and I were having a discussion in a separate doc about autofocus, which revealed that we probably should discuss focus in general.

My impression was that, like other top-level browsing contexts, portal browsing contexts would have an independent currently focused area (~document.activeElement). So e.g. code inside the portal could use autofocus="", element.focus(), etc., without impacting the embedder browsing context at all. focus and blur events would fire inside the portal browsing context, completely independent from the embedder browsing context. And, this currently focused area could be styled differently, e.g. matching :focus styles from that document.

@a4sriniv reports that currently portals are not implemented like that, and (IIUC) instead all attempts to focus something inside a portal browsing context are no-ops. In this model, document.activeElement inside a portal would be .... null? Or the <body> element? And focus and blur events would never fire, pre-activation. autofocus="" behavior is undetermined.

IMO, having independent focused areas is conceptually clean and simple. However, it does have the potential downside of the styling not matching user expectations. For example, if the portaled content contains a <input type=text autofocus>, it could have the blue focus outline, while at the same time something else on the outer page also has the blue focus outline. That'd be a pretty bad user experience, I think.

Are there other problems with the independent-areas model?

bokand commented 4 years ago

I think worse than styling would be a flashing input cursor since that implies the page is waiting for input. Keyboard coming up would be a concern but I believe that's gated on user activation so shouldn't be an issue; though I don't know that all browsers gate on that.

a4sriniv commented 4 years ago

Some more details about the current implementation:

with the current implmentation, document.activeElement inside a portal always returns <body>
we also do a "focus transfer" across activation (only if the predecessor page was focused before activation)
- the predecessor page loses page focus (we dispatch blur events on window and the previously focused element)
- the activated page gains page focus (dispatch focus event on window)

domenic commented 4 years ago

I think worse than styling would be a flashing input cursor since that implies the page is waiting for input

We don't have to show a cursor on everything that's focused, though. See below.

In general my leaning would be toward treating portals the same as other top-level BCs (e.g., window.open()ed tabs, which can have their own independent focused area). It appears we already have handling to not style or show the cursor for such browsing contexts, despite them having independently changing focused area. See the example at https://jsbin.com/luyejohodu/edit?html,output . So if the only downside is styling/cursor related, then that model makes sense to me.

WDYT?

a4sriniv commented 4 years ago

So I fiddled around some more with chrome's focus implementation, and observed a few things:

it looks like everytime we focus on a new window/tab, we actually send blur events to the previous window and the active element of the window's document
- we don't change the activeElement of the document though
- we also remove any of the focus styling that was previously applied
when we focus the previous window again, we dispatch a focus event to the document's activeElement again
if we call focus() on an element in a window that doesn't have focus, the document's activeElement is updated, but we do not dispatch a focus event
- it doesn't get any focus styling

I'm not sure any of this is speced anywhere (or maybe it is and I misinterpreted the current spec); but if we treated a portal like a window without focus, we would update the activeElement every time we call focus() in the portal's BC, but never actually dispatch any events. Portal activation would be equivalent to a window getting focus, and we would focus the document's activeElement (so autofocus would work). This seems to give it the top-level BC behaviour, and avoids the styling problems as well. WDYT?

domenic commented 3 years ago

Some of this is getting specced in https://github.com/whatwg/html/pull/6172, coincidentally.

domenic commented 3 years ago

Portal activation would be equivalent to a window getting focus, and we would focus the document's activeElement (so autofocus would work). This seems to give it the top-level BC behaviour, and avoids the styling problems as well. WDYT?

This seems perfect to me.

WICG / portals

Handling of focus inside a portal #257