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.

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

Jump to bottom

Non-bubbling event should run non-capture listeners #750

Merged
merged 1 commit into from Apr 15, 2019
Merged

Non-bubbling event should run non-capture listeners #750

Changes from all commits
Commits
Show all changes
1 commit
Select commit
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Jump to
Jump to file
Failed to load files.
Diff view
Diff view
14 changes: 10 additions & 4 deletions dom.bs
View file
Open in desktop
Expand Up @@ -1405,15 +1405,21 @@ for discussion).
</ol>

<li>
<p>If <var>event</var>'s {{Event/bubbles}} attribute is true, then <a for=list>for each</a>
<var>struct</var> in <var>event</var>'s <a for=Event>path</a>:
<p><a for=list>For each</a> <var>struct</var> in <var>event</var>'s <a for=Event>path</a>:

<ol>
<li><p>If <var>struct</var>'s <a for=Event/path>target</a> is non-null, then set
Copy link
Collaborator

Choose a reason for hiding this comment

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

I actually don't get this check. How can target ever be null?
Don't we need to check that target is equal to targetOverride instead?
In general, steps 5.9.7-9 seem to be in the need of a bit more clarification as to what they're trying to do.

Copy link
Member Author

Choose a reason for hiding this comment

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

An event's path consists of a list of structs. target is only non-null for the actual target and any shadow tree hosts that the actual target might be "nested" in.

Copy link
Collaborator

@rniwa rniwa Apr 11, 2019 •
edited

Choose a reason for hiding this comment

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

I understand that's what this sentence assumes but I don't see how such a condition is met given what's in https://dom.spec.whatwg.org/#concept-event-dispatch. It passes parent as the target of the struct in most cases and each get the parent relies on parent not being null. So I don't see how that's possible...

Copy link
Member Author

Choose a reason for hiding this comment

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

Yeah, but that argument is what becomes "item" on the struct, not "target". See https://dom.spec.whatwg.org/#concept-event-path-append. I agree this is somewhat confusing and I'd appreciate if someone could come up with better variable names as I'm still somewhat stuck.

Copy link
Collaborator

Choose a reason for hiding this comment

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

Oh, I see. That is indeed very confusing. Maybe we can use different variable names or something? Having item, target, & targetOverride is confusing enough.

<var>event</var>'s {{Event/eventPhase}} attribute to {{Event/AT_TARGET}}.

<li><p>Otherwise, set <var>event</var>'s {{Event/eventPhase}} attribute to
{{Event/BUBBLING_PHASE}}.
<li>
<p>Otherwise:

<ol>
<li><p>If <var>event</var>'s {{Event/bubbles}} attribute is false, then
<a for=iteration>continue</a>.

<li><p>Set <var>event</var>'s {{Event/eventPhase}} attribute to {{Event/BUBBLING_PHASE}}.
</ol>

<li><p><a>Invoke</a> with <var>struct</var>, <var>event</var>, "<code>bubbling</code>", and
<var>legacyOutputDidListenersThrowFlag</var> if given.
Expand Down