-
Notifications
You must be signed in to change notification settings - Fork 297
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
Adoption and DocumentFragment, part two #819
base: main
Are you sure you want to change the base?
Conversation
32cfc18
to
6eb77d0
Compare
See whatwg/dom#819. Verified with jsdom/jsdom#2925.
Anything I can help with on the jsdom side, or on reviews, to land this and the associated HTML/WPT PRs? |
8dafaf7
to
9a1e814
Compare
Verifying that this is correct would help as well as a review. Perhaps @mfreed7 is interested in prototyping in Chromium? |
The change looks reasonable, but from #814 it might be tricky to get exactly right. I'm happy to prototype in Chromium, but I'd prefer to do that after jsdom has had a chance to confirm the change passes existing WPTs... @TimothyGu? |
9a1e814
to
5c12594
Compare
5c12594
to
77ad4ca
Compare
The DOM spec is currently broken because of changes around the adoption of nodes. There is an open PR which reverts some of these changes. This implements the same changes as in that PR to fix issues where some mutations would otherwise generate invalid mutation records.
The DOM spec is currently broken because of changes around the adoption of nodes. There is an open PR which reverts some of these changes. This implements the same changes as in that PR to fix issues where some mutations would otherwise generate invalid mutation records.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Noneo8
This comment was marked as spam.
This comment was marked as spam.
Tests: web-platform-tests/wpt#22504. Corresponding HTML PR: whatwg/html#5413. Closes #813 and closes #814.
77ad4ca
to
7afc950
Compare
FWIW, I've implemented this new behavior in https://commits.webkit.org/252098@main |
<li> | ||
<p>If <var>node</var> is a {{DocumentFragment}} <a for=/>node</a> and its | ||
<a for=DocumentFragment>host</a> is non-null, then return <var>node</var>. | ||
|
||
<p class=note>Unfortunately this does not throw for web compatibility. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What does "does not throw for web compatibility" mean? Any one who employs template.content
node adoption before will now face with breakage with the sudden change of "whose host is non-null, then return".
If we no longer guarantee old API evolves without breaking, how do I find some rule of thumbs what is dangerous and what is not? An example issue is here aurelia/framework#1003
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bigopon before this change adoptNode()
would have returned undefined which would result in undefined behavior as its IDL claims its return value is a Node
.
From reading the issue you linked it seems that implementations never matched the specification and some applications (such as yours) relied on that. Perhaps we need to continue to allow that, but it would be a strange special case for HTMLTemplateElement
's DocumentFragment
usage as we cannot do the same thing if you were to pass a ShadowRoot
for instance. It would also result in a rather weird HTMLTemplateElement
instance, but since nothing much builds upon it maybe that is okay.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
From reading the issue you linked it seems that implementations never matched the specification and some applications (such as yours) relied on that.
That's not true. The implementations were according to the spec until #754, that inserted a rule about template's fragment for the first time.
That rule returned undefined, there were some issues with that and the browsers didn't implemented (according to this ).
Then with #819 the spec changed again.
On July webkit implemented the new rule. Before one month Safari went public with the new version of webkit and many applications broke on production.
And since then we are trying to figure out what's going on.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So it sounds from the linked issues and comment like this change isn't web compatible as-is, right? Sounds like another approach is needed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Any updates on this?
Right now our application is not working on Safari on production.
Webkit says that this is intentional behavior change and we don't know how to proceed to fix our application...
Is there a process that I need to follow or do I just create a PR to fix this? The easiest option is to revert the change and find a more reasonable one later. |
It's been awhile without answer, where can I shoot my concerns over this issues? It's breaking both apps and hearts. |
I believe you're referring to the WebKit/Safari behavior described here, correct? https://bugs.webkit.org/show_bug.cgi?id=246899 If so, that bug is the better place to raise the issue, since this issue is about the spec. That bug is informative about the direction the spec needs to take, though, since it seems the proposed direction isn't web compatible. |
so adoptNode behavior has been reverted in WebKit There is a need for a better path forward. |
What we want is the ability to adopt the document fragment. Currently adopting the template element doesn't adopt the document fragment itself. What if we do that? I dont know all the reasons why the fragment of the template element isn't associated with the document that created it, but if calling adoptNode explicitly on template does it then maybe this behavior is safe to go in? |
This reverts commit c825cea and adds a new solution for
DocumentFragment
adoption on top. See #813 and #814 for context.HTML: whatwg/html#5413
Tests: web-platform-tests/wpt#22504
jsdom: jsdom/jsdom#2925
Preview | Diff