Handle shadow host with delegatesFocus=true in focusing steps (click focus + focus()) #4796

rakina · 2019-07-24T13:01:44Z

At least two implementers are interested (and none opposed):
- Blink
- Gecko & Safari are reviewing the other PRs, so marking as interested
Tests are written and can be reviewed and commented upon at:
- HTML: Handle shadow host with delegatesFocus=true in Element.focus(), click and sequential focus navigation web-platform-tests/wpt#18035
Implementation bugs are filed:
- Chrome: TODO
- Firefox: TODO
- Safari: TODO

Another part of #2013 and whatwg/dom#768. Defines the behavior of focus() and the focusing steps in general.
Note that this is a change made on top of #4735, which defines flattened tabindex-ordered focus navigation scopes, etc. needed for this change.

Another note, the behavior in Chrome for focus() when the flattened tabindex-ordered focus navigation scope is empty (there's nothing to focus on) is kinda weird - it focuses on the host instead of not focusing on anything (crbug filed). I'm not sure if we want this behavior or not in the specs (the current PR aborts the focusing steps instead).

/browsing-the-web.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )
/references.html ( diff )

rakina · 2019-07-24T13:25:02Z

cc people involved in previous PRs @rniwa @annevk @domenic

source

domenic

I've squashed this to just two commits, 1e1697d which contains all of PR #4735, and 99c8181 which contains the new content for this pull request. I'm sorry GitHub doesn't have a better way to do dependent pull requests :-(.

Note that this handles the focusing steps generally, and so impacts things like:

autofocus
accesskey
fragment navigation

I think it does not impact sequential focus navigation, even though that algorithm calls the focusing steps, because the previous PR omits the host from the sequential focus navigation order.

This changes LGTM, although I will mark it "do not merge yet" since it's dependent on #4735 landing first.

domenic · 2019-07-30T18:44:47Z

Also let's call special attention to @rakina's note in the OP:

Another note, the behavior in Chrome for focus() when the flattened tabindex-ordered focus navigation scope is empty (there's nothing to focus on) is kinda weird - it focuses on the host instead of not focusing on anything (crbug filed). I'm not sure if we want this behavior or not in the specs (the current PR aborts the focusing steps instead).

It sounds like Chrome would prefer to abort focusing in such cases (e.g. delegatesFocus on a shadow host that has no children). Does that make sense to other browsers? We can certainly iterate on it later, similar to #4731 (comment) for :focus, but it's also nice to get folks impressions.

source

rniwa · 2019-08-17T00:01:26Z

Another note, the behavior in Chrome for focus() when the flattened tabindex-ordered focus navigation scope is empty (there's nothing to focus on) is kinda weird - it focuses on the host instead of not focusing on anything (crbug filed). I'm not sure if we want this behavior or not in the specs (the current PR aborts the focusing steps instead).

It sounds like Chrome would prefer to abort focusing in such cases (e.g. delegatesFocus on a shadow host that has no children). Does that make sense to other browsers? We can certainly iterate on it later, similar to #4731 (comment) for :focus, but it's also nice to get folks impressions.

We should do whatever matches when focusing an element that's not focusable, which is basically aborting.

rakina · 2019-08-27T05:41:49Z

Another note, the behavior in Chrome for focus() when the flattened tabindex-ordered focus navigation scope is empty (there's nothing to focus on) is kinda weird - it focuses on the host instead of not focusing on anything (crbug filed). I'm not sure if we want this behavior or not in the specs (the current PR aborts the focusing steps instead).

It sounds like Chrome would prefer to abort focusing in such cases (e.g. delegatesFocus on a shadow host that has no children). Does that make sense to other browsers? We can certainly iterate on it later, similar to #4731 (comment) for :focus, but it's also nice to get folks impressions.

We should do whatever matches when focusing an element that's not focusable, which is basically aborting.

SGTM! This matches the spec PR then.

smaug----

This isn't really reviewable since the patch has somehow #4735 in it.

rakina · 2019-09-02T20:55:08Z

This isn't really reviewable since the patch has somehow #4735 in it.

Here's the changes on top of that PR: 99c8181

rakina · 2019-09-20T06:36:27Z

Per WICG/webcomponents#830 (comment), this needs an update to use the flat tree order and also use the "click focusable" definition from #4768. I'll update this next week - in the meantime, @smaug---- and @rniwa can you review and maybe give approvals on #4735 and https://github.com/whatwg/html/pull/4768/files/4e2a998af84570fda3ff90d45a1882408c9f1cbb..75b444334fe8a77d6e26ee8b4c160ea6cebf3d93?

rakina · 2019-09-25T07:19:52Z

Rebased and updated the PR to use first in flat tree order (+ click focusable for focus). Note that sequential navigation focus delegation already works fine because we already skip hosts with delegatesFocus=true in sequential navigation.

domenic

I pushed a commit with some editorial changes (some to preexisting text, but I was in the area...), and also added a note explaining what you said about sequential focus navigation. This LGTM now.

@annevk, would you be able to do a final pass here? In particular this is the first use of flat tree ordering in the spec, so a second pair of eyes on that part would be helpful.

Wasn't a review

annevk · 2019-09-26T09:57:21Z

There's a couple things I don't quite understand:

Why do we still reference the box tree for some of this? Wouldn't the box tree also cross shadow tree boundaries, including those without delegate focus? I suspect we should update those to say flat tree as well with the appropriate checks (if flat tree allows for those checks, haven't checked).
How does this deal with recursion? If a shadow tree contains another shadow tree without delegate focus, it seems that only looking at the flat tree would blow straight past that.

emilio · 2019-09-26T10:15:55Z

Yeah, using the flat tree directly to dig down in the tree just ignores any other potential shadow tree which may have delegateFocus = false, I think... I think looking at flattened tree ancestors may be ok here, but downwards you get into funny behavior.

What Gecko implements for focus navigation in shadow trees (and as far as I can tell, that also matches Blink and WebKit) is mostly http://w3c.github.io/webcomponents/spec/shadow/#sequential-focus-navigation, why do we need to come up with yet a different algorithm for this case?

The code for focusing an element via focus() is https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/dom/base/nsFocusManager.cpp#1140

The code for click focus handling is here: https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/dom/events/EventStateManager.cpp#3035

And effectively just checks whether the event hasn't been prevented, and looks at focusability of the event target or any flattened tree ancestor.

rakina · 2019-09-26T11:10:25Z

@emilio: See this thread on why we want a different behavior, it was also talked about in TPAC: WICG/webcomponents#830 (comment)

…

On Thu, Sep 26, 2019, 19:16 Emilio Cobos Álvarez ***@***.***> wrote: Yeah, using the flat tree directly to dig down in the tree just ignores any other potential shadow tree which may have delegateFocus = false, I think... I think looking at flattened tree ancestors may be ok here, but downwards you get into funny behavior. What Gecko implements for focus navigation in shadow trees (and as far as I can tell, that also matches Blink and WebKit) is mostly http://w3c.github.io/webcomponents/spec/shadow/#sequential-focus-navigation, why do we need to come up with yet a different algorithm for this case? The code for focusing an element via focus() is https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/dom/base/nsFocusManager.cpp#1140 The code for click focus handling is here: https://searchfox.org/mozilla-central/rev/f43ae7e1c43a4a940b658381157a6ea6c5a185c1/dom/events/EventStateManager.cpp#3035 And effectively just checks whether the event hasn't been prevented, and looks at focusability of the event target or any flattened tree ancestor. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4796?email_source=notifications&email_token=ABPN2EVFPI6PKE5HNPZBR6TQLSDXFA5CNFSM4IGP2CK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7VCHSA#issuecomment-535438280>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPN2EVJNH7JW66XFDGGS7LQLSDXFANCNFSM4IGP2CKQ> .

rakina · 2019-09-27T00:57:25Z

Why do we still reference the box tree for some of this? Wouldn't the box tree also cross shadow tree boundaries, including those without delegate focus? I suspect we should update those to say flat tree as well with the appropriate checks (if flat tree allows for those checks, haven't checked).

I don't think I understand this, which part are you referring to?

How does this deal with recursion? If a shadow tree contains another shadow tree without delegate focus, it seems that only looking at the flat tree would blow straight past that.

I think this is OK. "delegates focus" doesn't mean "you now can focus on things inside my shadow tree", it only means "don't focus on the host". So even if a child shadow tree has delegatesFocus=false it doesn't mean "don't put focus on things inside", so there should be no problem of just using the flat tree order? As discussed in WICG/webcomponents#830, this behavior makes the focus delegation predictable and interoperable.

domenic

Per discussion in web-platform-tests/wpt#18035 (comment) we need to not use activation behavior here, but instead something like "when a user activates them". For now I think the best cross-reference for "activates" is just an <a href="#activation">. Eventually we may get better explanation for the end-to-end process of users activating things, by integrating with https://w3c.github.io/uievents/#event-flow-activation, but for now that seems good enough.

We may want to add an explicit <p class="note"> stating that focusing is not activation behavior, i.e. dispatching synthetic click events or calling click() will not cause focus.

rakina · 2019-09-27T04:33:31Z

Per discussion in web-platform-tests/wpt#18035 (comment) we need to not use activation behavior here, but instead something like "when a user activates them". For now I think the best cross-reference for "activates" is just an <a href="#activation">. Eventually we may get better explanation for the end-to-end process of users activating things, by integrating with https://w3c.github.io/uievents/#event-flow-activation, but for now that seems good enough.

We may want to add an explicit <p class="note"> stating that focusing is not activation behavior, i.e. dispatching synthetic click events or calling click() will not cause focus.

Added, thanks!

annevk · 2019-09-27T11:35:47Z

@rakina ah, thanks, and there's no chance of a descendant host getting focus while it should not?

As for "box tree", it's mentioned twice in HTML's focus sections and it seems somewhat redundant with "flat tree".

rakina · 2019-10-01T03:39:47Z

@rakina <https://github.com/rakina> ah, thanks, and there's no chance of a descendant host getting focus while it should not?

Yes, because hosts with delegatesFocus=true are not considered as focusable areas, so they'll never be in the "possible focus delegates" list.

As for "box tree", it's mentioned twice in HTML's focus sections and it

seems somewhat redundant with "flat tree". I see, you're right - I updated the PR to remove the ordering part and change box tree to flat tree in the other one. Thanks!

…

On Fri, Sep 27, 2019, 07:36 Anne van Kesteren ***@***.***> wrote: @rakina <https://github.com/rakina> ah, thanks, and there's no chance of a descendant host getting focus while it should not? As for "box tree", it's mentioned twice in HTML's focus sections and it seems somewhat redundant with "flat tree". — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#4796?email_source=notifications&email_token=ABPN2EXYXUZRK57BJLKUZQTQLXV2VA5CNFSM4IGP2CK2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD7YTXYQ#issuecomment-535903202>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABPN2ERFHXTMLK6ZCFE4IK3QLXV2VANCNFSM4IGP2CKQ> .

rniwa

r=me

rniwa · 2019-10-12T03:21:08Z

Great. Thanks for all your hard work, @rakina. I'm really excited that this feature is now fully spec'ed and implementable in WebKit. As a mater of fact, I've uploaded the patch to implement this new behavior in https://bugs.webkit.org/show_bug.cgi?id=166484.

Hopefully @smaug---- can do another pass of the PR and we can call it good.

https://bugs.webkit.org/show_bug.cgi?id=166484 <rdar://problem/29816058> Reviewed by Antti Koivisto. LayoutTests/imported/w3c: Import W3C tests from web-platform-tests/wpt@a8a89f2. * web-platform-tests/resources/testdriver-vendor.js: * web-platform-tests/shadow-dom/focus/click-focus-delegatesFocus-click-method-expected.txt: Added. * web-platform-tests/shadow-dom/focus/click-focus-delegatesFocus-click-method.html: Added. * web-platform-tests/shadow-dom/focus/click-focus-delegatesFocus-tabindex-varies-expected.txt: Added. * web-platform-tests/shadow-dom/focus/click-focus-delegatesFocus-tabindex-varies.html: Added. * web-platform-tests/shadow-dom/focus/click-focus-delegatesFocus-tabindex-zero-expected.txt: Added. * web-platform-tests/shadow-dom/focus/click-focus-delegatesFocus-tabindex-zero.html: Added. * web-platform-tests/shadow-dom/focus/focus-method-delegatesFocus-expected.txt: Added. * web-platform-tests/shadow-dom/focus/focus-method-delegatesFocus.html: Added. * web-platform-tests/shadow-dom/focus/focus-tabindex-order-shadow-negative-delegatesFocus-expected.txt: Added. * web-platform-tests/shadow-dom/focus/focus-tabindex-order-shadow-negative-delegatesFocus.html: Added. * web-platform-tests/shadow-dom/focus/focus-tabindex-order-shadow-varying-delegatesFocus-expected.txt: Added. * web-platform-tests/shadow-dom/focus/focus-tabindex-order-shadow-varying-delegatesFocus.html: Added. * web-platform-tests/shadow-dom/focus/focus-tabindex-order-shadow-zero-delegatesFocus-expected.txt: Added. * web-platform-tests/shadow-dom/focus/focus-tabindex-order-shadow-zero-delegatesFocus.html: Added. Source/WebCore: Implement delegatesFocus as specified in whatwg/html#4796 When the shadow root of an element has delegates focus flag set, focusing on the shadow host would automatically "delegates" focus to the first focusable element in the shadow tree instead. The first focusable element is determined as the first element that is programatically focusable or mouse focusable in the flat tree (composed tree in WebKit's terminology) in the case of the element getting focused via DOM API, Element.prototype.focus, by via mouse down. In the case of sequential focus navigation (via tab key), it's the first keyboard focusable element in the tabIndex order. Tests: imported/w3c/web-platform-tests/shadow-dom/focus/click-focus-delegatesFocus-click-method.html imported/w3c/web-platform-tests/shadow-dom/focus/click-focus-delegatesFocus-tabindex-varies.html imported/w3c/web-platform-tests/shadow-dom/focus/click-focus-delegatesFocus-tabindex-zero.html imported/w3c/web-platform-tests/shadow-dom/focus/focus-method-delegatesFocus.html imported/w3c/web-platform-tests/shadow-dom/focus/focus-tabindex-order-shadow-negative-delegatesFocus.html imported/w3c/web-platform-tests/shadow-dom/focus/focus-tabindex-order-shadow-varying-delegatesFocus.html imported/w3c/web-platform-tests/shadow-dom/focus/focus-tabindex-order-shadow-zero-delegatesFocus.html * dom/Element.cpp: (WebCore::Element::isKeyboardFocusable const): A shadow host with the delegates focus flag is not considered as keyboard focusable. The rest is taken care of by the existing logic in FocusController. (WebCore::isProgramaticallyFocusable): Extracted from Element::focus. (WebCore::findFirstProgramaticallyFocusableElementInComposedTree): Added. (WebCore::Element::focus): Added the support for delegatesFocus. * dom/Element.h: (WebCore::ShadowRootInit::delegatesFocus): Added. * dom/Element.idl: Ditto. * dom/ShadowRoot.cpp: (WebCore::ShadowRoot::ShadowRoot): Added delegatesFocus to the constructor. * dom/ShadowRoot.h: * page/EventHandler.cpp: (WebCore::findFirstMouseFocusableElementInComposedTree): Added. (WebCore::EventHandler::dispatchMouseEvent): Added the support for delegatesFocus. Uses the first mouse focusable element in the flat tree (composed tree) order. * page/FocusController.cpp: (WebCore::FocusController::findFirstFocusableElementInShadowRoot): * page/FocusController.h: git-svn-id: http://svn.webkit.org/repository/webkit/trunk@251043 268f45cc-cd09-0410-ab3c-d52691b4dbfc

rakina mentioned this pull request Jul 24, 2019

HTML: Handle shadow host with delegatesFocus=true in Element.focus(), click and sequential focus navigation web-platform-tests/wpt#18035

Merged

rniwa reviewed Jul 30, 2019

View reviewed changes

source Show resolved Hide resolved

rniwa reviewed Jul 30, 2019

View reviewed changes

source Outdated Show resolved Hide resolved

rniwa reviewed Jul 30, 2019

View reviewed changes

source Outdated Show resolved Hide resolved

domenic approved these changes Jul 30, 2019

View reviewed changes

domenic added addition/proposal New features or enhancements do not merge yet Pull request must not be merged per rationale in comment topic: focus labels Jul 30, 2019

domenic self-assigned this Jul 30, 2019

rniwa reviewed Aug 14, 2019

View reviewed changes

source Show resolved Hide resolved

annevk requested a review from smaug---- August 26, 2019 15:40

rakina mentioned this pull request Aug 28, 2019

Focus delegation from shadow host should not behave like sequential focus navigation WICG/webcomponents#830

Closed

domenic mentioned this pull request Aug 28, 2019

Add delegatesFocus init to attachShadow and flag to ShadowRoot whatwg/dom#768

Merged

smaug---- previously requested changes Sep 2, 2019

View reviewed changes

This was referenced Sep 20, 2019

Should host with delegatesFocus true keep the previous focused element focused if it's a shadow-including descendant of the host? WICG/webcomponents#840

Closed

Upstream focus navigation behavior for delegatesFocus from W3C spec. #2013

Closed

rakina changed the title ~~Handle shadow host with delegatesFocus=true in Element.focus()/focusing steps~~ Handle shadow host with delegatesFocus=true in focusing steps (click focus + focus()) Sep 25, 2019

domenic removed the do not merge yet Pull request must not be merged per rationale in comment label Sep 26, 2019

domenic approved these changes Sep 26, 2019

View reviewed changes

domenic requested changes Sep 27, 2019

View reviewed changes

rakina and others added 6 commits October 1, 2019 12:23

Handle shadow host with delegatesFocus=true in Element.focus()

c607b25

Rebase & use first in flat tree order

99079f1

Can only delegate focus to descendants

7e3ea9a

Add note about click()

a384915

Editorial tweaks, including to pre-existing text; add a note

5bf29d7

remove box tree

f90ea02

rniwa approved these changes Oct 12, 2019

View reviewed changes

domenic added 2 commits October 16, 2019 15:01

Final tweaksgit add .

36ed900

Also link activation behavior

f4f734a

domenic approved these changes Oct 16, 2019

View reviewed changes

domenic merged commit 133607f into whatwg:master Oct 16, 2019

romulocintra mentioned this pull request Oct 17, 2019

Expose ShadowDOM properties ionic-team/stencil#1623

Closed

siusin mentioned this pull request Apr 13, 2020

HTML Standard (Jan 2020): review tracker w3c/htmlwg#8

Open

8 tasks

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Handle shadow host with delegatesFocus=true in focusing steps (click focus + focus()) #4796

Handle shadow host with delegatesFocus=true in focusing steps (click focus + focus()) #4796

rakina commented Jul 24, 2019 •

edited by pr-preview bot

Loading

rakina commented Jul 24, 2019

domenic left a comment

domenic commented Jul 30, 2019

rniwa commented Aug 17, 2019

rakina commented Aug 27, 2019 •

edited

Loading

smaug---- left a comment

rakina commented Sep 2, 2019

rakina commented Sep 20, 2019

rakina commented Sep 25, 2019

domenic left a comment

annevk commented Sep 26, 2019

emilio commented Sep 26, 2019

rakina commented Sep 26, 2019 via email

rakina commented Sep 27, 2019

domenic left a comment

rakina commented Sep 27, 2019

annevk commented Sep 27, 2019

rakina commented Oct 1, 2019 via email •

edited

Loading

rniwa left a comment

rniwa commented Oct 12, 2019 •

edited

Loading

Handle shadow host with delegatesFocus=true in focusing steps (click focus + focus()) #4796

Handle shadow host with delegatesFocus=true in focusing steps (click focus + focus()) #4796

Conversation

rakina commented Jul 24, 2019 • edited by pr-preview bot Loading

rakina commented Jul 24, 2019

domenic left a comment

Choose a reason for hiding this comment

domenic commented Jul 30, 2019

rniwa commented Aug 17, 2019

rakina commented Aug 27, 2019 • edited Loading

smaug---- left a comment

Choose a reason for hiding this comment

rakina commented Sep 2, 2019

rakina commented Sep 20, 2019

rakina commented Sep 25, 2019

domenic left a comment

Choose a reason for hiding this comment

annevk commented Sep 26, 2019

emilio commented Sep 26, 2019

rakina commented Sep 26, 2019 via email

rakina commented Sep 27, 2019

domenic left a comment

Choose a reason for hiding this comment

rakina commented Sep 27, 2019

annevk commented Sep 27, 2019

rakina commented Oct 1, 2019 via email • edited Loading

rniwa left a comment

Choose a reason for hiding this comment

rniwa commented Oct 12, 2019 • edited Loading

rakina commented Jul 24, 2019 •

edited by pr-preview bot

Loading

rakina commented Aug 27, 2019 •

edited

Loading

rakina commented Oct 1, 2019 via email •

edited

Loading

rniwa commented Oct 12, 2019 •

edited

Loading