Add the initial support for shadow dom selection
Categories
(Core :: DOM: Core & HTML, task)
Tracking
()
Tracking | Status | |
---|---|---|
firefox126 | --- | fixed |
People
(Reporter: sefeng, Assigned: sefeng)
References
(Blocks 3 open bugs, Regressed 2 open bugs)
Details
(Keywords: dev-doc-needed)
Attachments
(12 files, 6 obsolete files)
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review | |
48 bytes,
text/x-phabricator-request
|
Details | Review |
Assignee | ||
Comment 1•11 months ago
|
||
This patch implements the .direction attribute
Spec: https://www.w3.org/TR/selection-api/#dom-selection-direction
Assignee | ||
Comment 2•11 months ago
|
||
A new type range called CrossBoundaryRange is introduced and attached
to a nsRange when needed. Unlike nsRange::mStart and nsRange::mEnd where
we collapse to one point when the start and the end are in different
DOM trees (ie, crossing shadow boundary), CrossBoundaryRange keeps
the the original start and the end.
Depends on D195301
Assignee | ||
Comment 3•11 months ago
|
||
Spec: https://www.w3.org/TR/selection-api/#ref-for-dom-selection-getcomposedranges-1
Depends on D195302
Assignee | ||
Comment 4•11 months ago
|
||
This is mainly used for nsINode::IsMaybeSelected() to work for nodes
inside shadow tree.
Depends on D195303
Assignee | ||
Comment 5•11 months ago
|
||
Depends on D195304
Assignee | ||
Comment 6•11 months ago
|
||
With the abiliity to disable it as well
Depends on D195305
Assignee | ||
Comment 7•11 months ago
|
||
Depends on D195306
Assignee | ||
Comment 8•11 months ago
|
||
Depends on D195307
Assignee | ||
Comment 9•11 months ago
|
||
Depends on D195308
Assignee | ||
Comment 10•11 months ago
|
||
Depends on D195309
Assignee | ||
Comment 11•11 months ago
|
||
Depends on D195310
Assignee | ||
Comment 12•11 months ago
|
||
Depends on D195311
Assignee | ||
Comment 13•11 months ago
|
||
Depends on D195312
Assignee | ||
Comment 14•11 months ago
|
||
Depends on D195313
Updated•11 months ago
|
Assignee | ||
Comment 15•10 months ago
|
||
Depends on D195314
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Assignee | ||
Comment 16•10 months ago
|
||
Depends on D196117
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•10 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•9 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Updated•8 months ago
|
Assignee | ||
Comment 18•8 months ago
|
||
Assignee | ||
Comment 20•8 months ago
|
||
Updated•8 months ago
|
Updated•8 months ago
|
Comment 21•7 months ago
|
||
Comment 23•7 months ago
•
|
||
Backed out for causing bustages on AbstractRange.cpp
Comment 25•7 months ago
|
||
Assignee | ||
Updated•7 months ago
|
Comment 26•7 months ago
|
||
bugherder |
https://hg.mozilla.org/mozilla-central/rev/0b237fd5577a
https://hg.mozilla.org/mozilla-central/rev/713c66e124c7
https://hg.mozilla.org/mozilla-central/rev/0710183c2311
https://hg.mozilla.org/mozilla-central/rev/02d89b880ac5
https://hg.mozilla.org/mozilla-central/rev/b1f1e6ad93f8
https://hg.mozilla.org/mozilla-central/rev/3990acf05c58
https://hg.mozilla.org/mozilla-central/rev/d665bdcc228a
https://hg.mozilla.org/mozilla-central/rev/edcf770a3a1d
https://hg.mozilla.org/mozilla-central/rev/adc0f4aa70db
https://hg.mozilla.org/mozilla-central/rev/7340930e5a53
https://hg.mozilla.org/mozilla-central/rev/6a4069c6ee10
https://hg.mozilla.org/mozilla-central/rev/ca6c1077eb87
Comment 28•6 months ago
|
||
FF126 MDN work for this can be tracked in https://github.com/mdn/content/issues/33180
I have some questions:
- This appears to add support for
Selection.direction
andSelection.getComposedRange()
.- Is that it? I mean the original explainer had a whole section Changes to existing Selection APIs - did that stuff happen too?
Selection.getComposedRange()
returns an array ofStaticRange
. Is it correct that all current implementations in practise return a single range?- This is named composed range.
- Reading around that seems to indicate that the range you get back is different from the old selections. It sounds like those are nodes and offsets, while "composed" might be a kind of flattened version that reflects the components as the UI would render them.
- SO I'm "guessing" that this means a simplified version. Is this "close" to the right view of things, and what impact does using composed range have on users?
- What do they have to think about because of this?
- This returns a
StaticRange
. Reading the docs it sounds like this is the range at the time you got the selection.- So If the underlying DOM changes the
StaticRange
will be incorrect - presumably selecting something else? - What are the implications for someone using this? They have to make sure they fetch a new range every time their is a DOM change?
- So If the underlying DOM changes the
Bit out of my depth on this.
Updated•6 months ago
|
Assignee | ||
Comment 29•6 months ago
|
||
This appears to add support for Selection.direction and Selection.getComposedRange().
Is that it? I mean the original explainer had a whole section Changes to existing Selection APIs - did that stuff happen too?
Some of those stuff happened but some of them didn't....
-
Selection.getRangeAt()
should return ... - This didn't happen -
Selection.anchorNode/anchorOffset/focusNode/focusOffset
should return ...- This didn't happen -
Selection.setBaseAndExtent()
should now accept .... - This happened -
Selection.collapse()
should now accept ... - This happened -
Selection.collapseToEnd()/collapseToStart()
should .... - This didn't happen -
deleteFromDocument()
should .... - This didn't happen -
extend()
should .... This happened -
User selection via mouse, keyboard, etc
.... This happened
Selection.getComposedRange() returns an array of StaticRange. Is it correct that all current implementations in practise return a single range?
In practice, only Firefox can return multiple ranges, other implementations can only return one range at max.
This is named composed range....
Reading around that seems to indicate that the range you get back is different from the old selections. It sounds like those are nodes and offsets, while "composed" might be a kind of flattened version that reflects the components as the UI would render them.
SO I'm "guessing" that this means a simplified version. Is this "close" to the right view of things, and what impact does using composed range have on users?
What do they have to think about because of this?
So basically it'll return the "true range" if the user provides the correct shadow roots of the corresponding boundaries.
And if the correct shadow roots are not provided, it'll rescope the boundaries to parent element of the root's host element (
if the parent is still in a shadow tree, it'll keep rescoping until the root is not a shadow root)
I think it makes sense to call this "close" to the right view of the boundaries. Speaking of impacts...I am not sure,
it's not going to be very useful if they don't provide the shadow roots. Though it's still better than calling
getRangeAt()
because the range returned by getRangeAt()
is going to be a collapsed range (at least in Firefox), which is even less useful.
This returns a StaticRange. Reading the docs it sounds like this is the range at the time you got the selection.
So If the underlying DOM changes the StaticRange will be incorrect - presumably selecting something else?
What are the implications for someone using this? They have to make sure they fetch a new range every time their is a DOM change?
Yeah, if the underlying DOM changes, the returned static range will be incorrect. In fact, if DOM mutation
happens, the entire "true range" can be incorrect, because the correct behaviour is undefined at the moment.
See https://github.com/w3c/selection-api/issues/168. So develpers should aware of these issues.
Hamish, hope this shed some lights, let me know if I can help more. Thanks
Comment 30•6 months ago
|
||
Thanks very much Sean - that's very helpful.
-
I have captured the "other API" compatibility changes in https://github.com/mdn/browser-compat-data/pull/23013
- Is it correct these are all behind the same preference and also that they are standard (such as, returning multiple ranges)
- I have marked that we are the only ones who have implemented all this new stuff so far - is that correct as far as we know.
- For the the parts above that were not done, is that because they didn't make it into the spec, or they just haven't been implemented by anyone yet?
-
So with respect to a change to the underlying DOM, what should a user DO now? Can they monitor for such changes and re-fetch a range in some way? I mean I can document that this might happen, but it would be even better to be able to say "you can monitor for mutations by doing X, and fix them by doing Y".
My "guess" is that you might be able to monitor for mutations (?) but if the nodes in the range could just become completely wrong, you might as well just throw away the selection at that point, or perhaps again "rescope to the parent of the shadow dom".
Updated•6 months ago
|
Assignee | ||
Comment 31•6 months ago
|
||
Is it correct these are all behind the same preference and also that they are standard (such as, returning multiple ranges)
Yeah, they all behind the same preference. Returning multiple ranges isn't a standardized behaviour, in fact the spec only asks to return one range.
I have marked that we are the only ones who have implemented all this new stuff so far - is that correct as far as we know.
Safari also have the getComposedRanges
and selection.direction
implement, I think Chrome doesn't, but some of the APIs might work in Chrome.
For the the parts above that were not done, is that because they didn't make it into the spec, or they just haven't been implemented by anyone yet?
Yeah...it's a mix of both. Really need to look this case-by-case. i.e, getRangeAt
should be updated to include that rescope
algorithm, but for things like collapseToEnd
, it's just I didn't implement it.
So with respect to a change to the underlying DOM, what should a user DO now? Can they monitor for such changes and re-fetch a range in some way? I mean I can document that this might happen, but it would be even better to be able to say "you can monitor for mutations by doing X, and fix them by doing Y".
So if developers want to update the selection, they can use MutationObserver
to monitor DOM mutations and then calling setBaseAndExtent
to update it. To monitor the selection made by users, I think they should remain to do what they are currently doing? I think the scenario should be pretty much the same as without ShadowDOM selection.
Let me know if I can clarify more things!
Comment 32•6 months ago
|
||
Thanks very much Sean! I'll ping you if I need more.
Changes to things such as collapseToEnd aren't always obvious to writers or the browser compat tests, both of which rely on the IDL having a visible change.
So when/if you implement these, please highlight them by marking the bug as dev-docs-needed and adding a specific note.
Comment 33•5 months ago
|
||
Sean, mostly just for my interest:
- I understand that
getComposedRanges()
returns a single range in the spec, but Firefox can return multiple range objects Selection.direction
returns the direction of a selection. But if a selection covers multiple ranges, to which selection does the value apply?
Assignee | ||
Comment 34•5 months ago
|
||
It's the direction of the most recent selection.
Description
•