Handling of focus inside a portal #257

domenic · 2020-11-09T22:47:42Z

@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?

The text was updated successfully, but these errors were encountered:

bokand · 2020-11-10T04:00:35Z

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 · 2020-11-10T13:25:32Z

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 · 2020-11-10T17:15:28Z

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 · 2020-11-24T20:08:40Z

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 · 2020-12-02T17:10:47Z

Some of this is getting specced in whatwg/html#6172, coincidentally.

domenic · 2020-12-02T17:13:14Z

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.

Allows a portal document's activeElement to update when focus is called. Note that focus events won't be dispatched as the portal doesn't get page focus, and the portal WebContents isn't set as the focused WebContents (with the exception of orphaned portals). Updating the activeElement also means an autofocused element inside a portal will receive focus when the portal is activated. More discussion here: WICG/portals#257 Change-Id: If67be1f424114653983b473a80c515337d49596a Bug: 1059404

Allows a portal document's activeElement to update when focus is called. Note that focus events won't be dispatched as the portal doesn't get page focus, and the portal WebContents isn't set as the focused WebContents (with the exception of orphaned portals). Updating the activeElement also means an autofocused element inside a portal will receive focus when the portal is activated. More discussion here: WICG/portals#257 Change-Id: If67be1f424114653983b473a80c515337d49596a Bug: 1059404 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2566072 Commit-Queue: Adithya Srinivasan <[email protected]> Reviewed-by: Lucas Gadani <[email protected]> Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Alex Moshchuk <[email protected]> Reviewed-by: David Trainor <[email protected]> Cr-Commit-Position: refs/heads/master@{#853647}

…ange active element, a=testonly Automatic update from web-platform-tests Portals: focus() inside portal should change active element Allows a portal document's activeElement to update when focus is called. Note that focus events won't be dispatched as the portal doesn't get page focus, and the portal WebContents isn't set as the focused WebContents (with the exception of orphaned portals). Updating the activeElement also means an autofocused element inside a portal will receive focus when the portal is activated. More discussion here: WICG/portals#257 Change-Id: If67be1f424114653983b473a80c515337d49596a Bug: 1059404 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2566072 Commit-Queue: Adithya Srinivasan <[email protected]> Reviewed-by: Lucas Gadani <[email protected]> Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Alex Moshchuk <[email protected]> Reviewed-by: David Trainor <[email protected]> Cr-Commit-Position: refs/heads/master@{#853647} -- wpt-commits: a507854e826d126010758ba44847d1b67fb29c01 wpt-pr: 27461

…ange active element, a=testonly Automatic update from web-platform-tests Portals: focus() inside portal should change active element Allows a portal document's activeElement to update when focus is called. Note that focus events won't be dispatched as the portal doesn't get page focus, and the portal WebContents isn't set as the focused WebContents (with the exception of orphaned portals). Updating the activeElement also means an autofocused element inside a portal will receive focus when the portal is activated. More discussion here: WICG/portals#257 Change-Id: If67be1f424114653983b473a80c515337d49596a Bug: 1059404 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2566072 Commit-Queue: Adithya Srinivasan <adithyaschromium.org> Reviewed-by: Lucas Gadani <lfgchromium.org> Reviewed-by: Jeremy Roman <jbromanchromium.org> Reviewed-by: Alex Moshchuk <alexmoschromium.org> Reviewed-by: David Trainor <dtrainorchromium.org> Cr-Commit-Position: refs/heads/master{#853647} -- wpt-commits: a507854e826d126010758ba44847d1b67fb29c01 wpt-pr: 27461 UltraBlame original commit: 7e6160586f3c29315b5b2267b293ecbdfefd4324

Allows a portal document's activeElement to update when focus is called. Note that focus events won't be dispatched as the portal doesn't get page focus, and the portal WebContents isn't set as the focused WebContents (with the exception of orphaned portals). Updating the activeElement also means an autofocused element inside a portal will receive focus when the portal is activated. More discussion here: WICG/portals#257 Change-Id: If67be1f424114653983b473a80c515337d49596a Bug: 1059404 Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/2566072 Commit-Queue: Adithya Srinivasan <[email protected]> Reviewed-by: Lucas Gadani <[email protected]> Reviewed-by: Jeremy Roman <[email protected]> Reviewed-by: Alex Moshchuk <[email protected]> Reviewed-by: David Trainor <[email protected]> Cr-Commit-Position: refs/heads/master@{#853647} GitOrigin-RevId: 11c3d6ba0f0c5e26aec2c764f9f95d037c23fc10

domenic added the design work needed An acknowledged gap in the proposal that needs design work to resolve label Nov 9, 2020

domenic mentioned this issue Nov 22, 2020

Back-forward cache: Restoring focus whatwg/html#5878

Closed

domenic mentioned this issue Dec 2, 2020

Have document.hasFocus() and blur/focus events reveal system-level focus whatwg/html#6172

Merged

2 tasks

chromium-wpt-export-bot mentioned this issue Feb 3, 2021

Portals: focus() inside portal should change active element web-platform-tests/wpt#27461

Merged

a4sriniv mentioned this issue Mar 18, 2021

Clarify prerendering documents cannot have focus. WICG/nav-speculation#55

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handling of focus inside a portal #257

Handling of focus inside a portal #257

domenic commented Nov 9, 2020 •

edited

Loading

bokand commented Nov 10, 2020

a4sriniv commented Nov 10, 2020

domenic commented Nov 10, 2020

a4sriniv commented Nov 24, 2020

domenic commented Dec 2, 2020

domenic commented Dec 2, 2020

Handling of focus inside a portal #257

Handling of focus inside a portal #257

Comments

domenic commented Nov 9, 2020 • edited Loading

bokand commented Nov 10, 2020

a4sriniv commented Nov 10, 2020

domenic commented Nov 10, 2020

a4sriniv commented Nov 24, 2020

domenic commented Dec 2, 2020

domenic commented Dec 2, 2020

domenic commented Nov 9, 2020 •

edited

Loading