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 all 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
25 changes: 17 additions & 8 deletions source
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -80593,11 +80593,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 @@ -80651,15 +80650,25 @@ 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>

<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>If <var>event</var>'s <span data-x="concept-event-target">target</span> 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>event</var>'s <span data-x="concept-event-target">target</span>.</p></li>
</ol>

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.

<h3>Focus</h3>

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