Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Define DocumentOrShadowRoot.activeElement #4837

Merged
merged 5 commits into from Aug 23, 2019

Conversation

@rakina
Copy link
Contributor

rakina commented Aug 12, 2019

  • 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:
  • Implementation bugs are filed:
    • Chrome: already implemented in Chrome
    • Firefox: already implemented in Firefox
    • Safari: already implemented in Safari

Another part of #2013 and whatwg/dom#768. Moves Document.activeElement to DocumentOrShadowRoot.activeElement


/dom.html ( diff )
/index.html ( diff )
/infrastructure.html ( diff )
/interaction.html ( diff )

@rakina

This comment has been minimized.

Copy link
Contributor Author

rakina commented Aug 12, 2019

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

Copy link
Member

domenic left a comment

I pushed some editorial tweaks, but I'd like your help fixing up the domintro for web developers.

source Show resolved Hide resolved
@rniwa

This comment has been minimized.

Copy link
Collaborator

rniwa commented Aug 13, 2019

@rakina

This comment has been minimized.

Copy link
Contributor Author

rakina commented Aug 13, 2019

FWIW, we've had this implemented in WebKit for a while:
https://trac.webkit.org/browser/webkit/trunk/Source/WebCore/dom/DocumentOrShadowRoot.idl?annotate=blame#L36

Thanks, updated the first post!

@EdgarChen

This comment has been minimized.

source Show resolved Hide resolved
@rniwa

This comment has been minimized.

Copy link
Collaborator

rniwa commented Aug 14, 2019

I guess activeElement's behavior won't be affected by delegatesFocus?

@rniwa

This comment has been minimized.

Copy link
Collaborator

rniwa commented Aug 14, 2019

Hm... now that I'm going through some of the tests @rakina wrote, I see that ShadowRoot.activeElement wouldn't point to a slot even if the element inside the slot had a focus. This is kind of a shitty behavior but it'll probably pose too much compatibility risk to change that now. :(

@rniwa

This comment has been minimized.

Copy link
Collaborator

rniwa commented Aug 15, 2019

Oh I guess I should have waited for this PR to be merged before merging the WPT PR. But it looks like the remaining issues is really an editorial one so we should just fix that up & merge the PR.

Copy link
Member

domenic left a comment

Some algorithm tweaks needed. Also, I am curious about the fullscreen connection, e.g. maybe we could use retargeting but then return null if not in the same tree, like fullscreen does.

source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
source Show resolved Hide resolved
@rakina

This comment has been minimized.

Copy link
Contributor Author

rakina commented Aug 23, 2019

Some algorithm tweaks needed. Also, I am curious about the fullscreen connection, e.g. maybe we could use retargeting but then return null if not in the same tree, like fullscreen does.

Oh hey you're right, we can actually just retarget and check if the result's root is the DocumentOrShadowRoot! Thank you :D

@domenic domenic removed the needs tests label Aug 23, 2019
@domenic domenic merged commit 5b84d19 into whatwg:master Aug 23, 2019
2 checks passed
2 checks passed
Participation rakina participates on behalf of Google LLC
Details
continuous-integration/travis-ci/pr The Travis CI build passed
Details
@saschanaz saschanaz referenced this pull request Sep 27, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
5 participants
You can’t perform that action at this time.