Skip to content

Improve CommandEvent and ToggleEvent source retargeting #11345

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.

Sign up for GitHub

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

Open
wants to merge 6 commits into
base: main
Choose a base branch
from
Open

Improve CommandEvent and ToggleEvent source retargeting #11345

Changes from 3 commits
Commits
Show all changes
6 commits
Select commit Hold shift + click to select a range
9b41097
Improve CommandEvent.source retargeting
josepharhar May 29, 2025
33ce103
Merge branch 'main' into sourceretarget
josepharhar Jun 2, 2025
68da488
retarget toggleevent.source
josepharhar Jun 2, 2025
f5d97a2
stop using currentTarget
josepharhar Jun 17, 2025
894dd14
Merge branch 'main' into sourceretarget
josepharhar Jul 8, 2025
6bd255f
fix retargetAgainst
josepharhar Jul 8, 2025
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
30 changes: 22 additions & 8 deletions source
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80604,11 +80604,10 @@ dictionary <dfn dictionary>ToggleEventInit</dfn> : <span>EventInit</span> {
data-x="dom-ToggleEvent-newState">newState</code></dfn> attributes must return the values they are
initialized to.</p>

<p>The <dfn attribute for="ToggleEvent"><code
data-x="dom-ToggleEvent-source">source</code></dfn> getter steps are to return the result of
<span data-x="dom-retarget">retargeting</span> <code
data-x="dom-ToggleEvent-source">source</code> against <span>this</span>'s <code
data-x="dom-Event-currentTarget">currentTarget</code>.</p>
<p>The <dfn attribute for="ToggleEvent"><code data-x="dom-ToggleEvent-source">source</code></dfn>
getter steps are to return the result of <span>retarget against an event</span> given
<span>this</span> and <span>this</span>'s <code
data-x="dom-ToggleEvent-source">source</code>.</p>

<p class="XXX"><a href="https://github.com/whatwg/dom/issues/1328">DOM standard issue #1328</a>
tracks how to better standardize associated event data in a way which makes sense on Events.
Expand Down Expand Up @@ -80662,15 +80661,30 @@ dictionary <dfn dictionary>CommandEventInit</dfn> : <span>EventInit</span> {

<p>The <dfn attribute
for="CommandEvent"><code data-x="dom-CommandEvent-source">source</code></dfn> getter steps are to
return the result of <span data-x="dom-retarget">retargeting</span> <code
data-x="dom-CommandEvent-source">source</code> against <span>this</span>'s <code
data-x="dom-Event-currentTarget">currentTarget</code>.</p>
return the result of <span>retarget against an event</span> given <span>this</span> and
<span>this</span>'s <code data-x="dom-CommandEvent-source">source</code>.</p>

<p class="XXX"><a href="https://github.com/whatwg/dom/issues/1328">DOM standard issue #1328</a>
tracks how to better standardize associated event data in a way which makes sense on Events.
Currently an event attribute initialized to a value cannot also have a getter, and so an internal
slot (or map of additional fields) is required to properly specify this.</p>

Copy link

@smaug---- smaug---- Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I still don't understand what we're trying to fix here. The current setup doesn't leak shadow DOM .source, or I don't understand how it does that. Could you explain?

Copy link
Member

@annevk annevk Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It would only leak if you create a synthetic event with source set to something in a shadow tree. Or if a new specification comes along that does something similar and reuses this event class. The question has become if we should put in protections for these cases as well. I kinda think we should.

I still don't understand why this is not the same as relatedTarget though. It seems weird to have a completely different mechanism.

Copy link

@smaug---- smaug---- Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why would it leak even with synthetic events?

Copy link
Member

@annevk annevk Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you don't retarget wouldn't it just return the node it was set to? Which could be from a shadow tree?

Copy link
Member

@keithamus keithamus Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It actually looks like neither Chrome nor Firefox follow the existing spec, as is written today. The spec today says:

The source getter steps are to return the result of retargeting source against this's currentTarget.

But both implementations do more like:

The source getter steps are to return the result of retargeting source against this's currentTarget if currentTarget is not null, otherwise return source.

This can be seen in the Chrome implementation of command_event.cc L46-50:

  if (current) {
    return &current->ToNode()->GetTreeScope().Retarget(*source);
  }
  DCHECK_EQ(eventPhase(), Event::PhaseType::kNone);
  return source;

And in the Firefox implementation CommandEvent.cpp L83-93:

  if (currentTarget) {
    nsINode* currentTargetNode = currentTarget->GetAsNode();
    if (!currentTargetNode) {
      return nullptr;
    }
    nsINode* retargeted = nsContentUtils::Retarget(
        static_cast<nsINode*>(mSource), currentTargetNode);
    return retargeted ? retargeted->AsElement() : nullptr;
  }
  MOZ_ASSERT(!mEvent->mFlags.mIsBeingDispatched);
  return mSource;

So the spec is right and two impls are wrong. If the implementations followed the spec this would be a non-issue, and this PR is perhaps redundant.

Copy link

@smaug---- smaug---- Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If you don't retarget wouldn't it just return the node it was set to? Which could be from a shadow tree?

there is already the existing retarget in the spec.

Copy link
Member

@annevk annevk Aug 14, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I see, your concern is with the rewrite in particular, not with retargeting in general. Glad we're in agreement on retargeting in general. @keithamus or @josepharhar will have to answer this then.

<p>To <dfn>retarget against an event</dfn>, given an <code>Event</code> <var>event</var> and a
<code>Node</code> <var>node</var>:</p>

<ol>
<li><p>Let <var>retargetAgainst</var> be <var>event</var>'s <code
data-x="dom-Event-currentTarget">currentTarget</code>.</p></li>

<li><p>If <var>retargetAgainst</var> is null, then set <var>retargetAgainst</var> to
<var>event</var>'s <span data-x="concept-event-target">target</span>.</p></li>
Copy link

@smaug---- smaug---- Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't understand this setup. We want events which have been dispatched in light DOM to have their .source retargeted? What is the use case for that. Events dispatched in shadow DOM would get just null.

Copy link
Contributor Author

@josepharhar josepharhar Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We want events which have been dispatched in light DOM to have their .source retargeted?

If the event has been dispatched in light DOM, then retargeting won't change the resulting source element that we return; we are effectively not retargeting events that are dispatched in light DOM.

Events dispatched in shadow DOM would get just null.

If the event was dispatched in shadow DOM, then source will become null after event dispatch is done, just like target and relatedTarget.

Copy link

@smaug---- smaug---- Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the event has been dispatched in light dom and source is in shadow DOM, retargeting will happen.

But what are we trying to achieve with this rather unusual setup? Why do we need to fall back to 'target'?

Copy link
Contributor Author

@josepharhar josepharhar Jun 11, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If the event has been dispatched in light dom and source is in shadow DOM, retargeting will happen.

Ah yes, that is true. In this case, I'm assuming that you still don't want source to be leaked somewhere since it is in a shadow root, so we should do retargeting.

But what are we trying to achieve with this rather unusual setup? Why do we need to fall back to 'target'?

Target is better than currentTarget because after event dispatch target is likely still set to something we can retarget against which won't leak any nodes, whereas currentTarget just becomes null.

Now that I think about it, maybe we can just always retarget against target instead of currentTarget

Copy link
Contributor Author

@josepharhar josepharhar Jun 17, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I removed the usage of currentTarget and now it just uses target. It shouldn't change the behavior.

Copy link
Member

@annevk annevk Jun 18, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is that also what happens for relatedTarget? Ideally source works the same way as relatedTarget.

Copy link

@smaug---- smaug---- Jul 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

retargetAgainst isn't defined anywhere

Copy link

@smaug---- smaug---- Jul 4, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But what is actually wrong with the current .source handling. I'm still not quite sure what we're trying to fix here. The current spec retargets shadow course to first light DOM host after dispatch. And during dispatch it is retargeted so that .source will be in the same or "higher" subtree than currentTarget/target.

The discussion about having relatedTarget type of behavior is more about tweaking the propagation path if we kept command event as composed, since once relatedTarget and target are in the same subtree, the event won't propagate higher up.
https://dom.spec.whatwg.org/#dispatching-events 6.9.7

Copy link
Contributor Author

@josepharhar josepharhar Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

retargetAgainst isn't defined anywhere

Thanks, I fixed that.

But what is actually wrong with the current .source handling.

Since it returns the original source element when currentTarget is not set, after event dispatch you can get the original element without retargeting: #11255 (comment)

The discussion about having relatedTarget type of behavior is more about tweaking the propagation path if we kept command event as composed, since once relatedTarget and target are in the same subtree, the event won't propagate higher up.

I agree, I made this more simple assuming that we are going to make the command event not composed.

Copy link

@smaug---- smaug---- Jul 8, 2025

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Since it returns the original source element when currentTarget is not set

Well, only if the original source element is in light DOM.


<li><p>If <var>retargetAgainst</var> is null, then return null.</p></li>

<li><p>Return the result of <span data-x="dom-retarget">retargeting</span> <var>node</var>
against <var>retargetAgainst</var>.</p></li>
</ol>

<h3>Focus</h3>

<!-- https://software.hixie.ch/utilities/js/live-dom-viewer/?saved=2807 -->
Expand Down