Coalesced and predicted event attributes within an untrusted event

[mustaqahmed]

The spec Sec 10 mentions the following about the attributes of the "contained events" for a JS-constructed (untrusted) event, which needs a clarification for at least isTrusted and target attributes:

Untrusted events have their coalesced/predicted events list initialized to the value passed to the constructor.

This text seems to suggest that the constructor allows setting any arbitrary value to an attribute. However, when I run the following code in Chrome and Firefox:

// Read default values:
let e0 = new PointerEvent("pointermove");
console.log(e0.isTrusted, e0.bubbles, e0.clientX, e0.pointerType, e0.target);
// Read assigned values:
let e1 = new PointerEvent("pointermove", {isTrusted: true, bubbles: true, clientX: 1234, pointerType: "hand", target: document.body});
console.log(e1.isTrusted, e1.bubbles, e1.clientX, e1.pointerType, e1.target);

both browsers emit the following:

false false 0 '' null
false true 1234 'hand' null

So isTrusted and target attributes do not allow arbitrary values while other attributes allow. I didn't see any indication in IDLs to explain this behavior!

In any case, we need clarifications for those two special attributes in coalesced and predicted event lists:

• Within a JS-constructed "parent" event, will they always have their default values?
• When a trusted "parent" event is redispatched from JS, will they be reset to their default values?

[mustaqahmed]

FYI @smaug---- @flackr

[smaug----]

There is no isTrusted property in the *EventInit, and there is no target.

I'm confused about this issue. The sentence in the spec talks about how one can initialize coalesced and predicted events lists. PointerEventInit has properties for those.

JS created event is always non-trusted, so redispatching doesn't affect .target of coalesced/predicted events.

[mustaqahmed]

Thanks @smaug----, that answers my first question.

My second question remains. To clarify, this is about JS re-dispatch of browser-constructed event. Something like this with the user moving the mouse over target2:

target1.onpointermove = e => console.log(e.getCoalescedEvents()[0].isTrusted);
target2.onpointermove = e => setTimeout(() => target1.dispatchEvent(e), 0);

(I am landing a tentative WPT for this.)

[mustaqahmed]

FYI: both Firefox and Chromium emit true from the repro I just posted, and I found it questionable.

[smaug----]

Oh, the "parent" event has been dispatched once, and then you redispatch it again? I wouldn't expect anything to change for coalesced or predicted events

[flackr]

I'm remembering now that previously we decided these additional structures would be treated as completely generic objects for developer dispatched events. This makes sense since the user could put anything they want in the coalescedEvents / predictedEvents lists, and I guess as such developers shouldn't trust the isTrusted flag or target attribute on those events if the isTrusted on the root event is false.

[mustaqahmed]

Well, the JS seems unable to construct a new PointerEvent object with e.isTrusted == true, and can't even change the same attribute in an existing PointerEvent object (trusted or not). Maybe this is because of the IDL for isTrusted, not sure:

[LegacyUnforgeable] readonly attribute boolean isTrusted;

Did I miss anything? At least the spec needs a clarification, right?

[smaug----]

That is the whole point of isTrusted. It is set to true only for events which UA dispatches. If an event was trusted and it is later re-dispatched using JS, it becomes untrusted.

[mustaqahmed]

Exactly! Therefore the current behavior essentially says "the isTrusted bits inside coalesced/predicted lists are always set by the browser yet they don't reflect if the events are really trusted or not". I find it super-confusing for developers.

If we want to maintain this behavior, I would suggest adding a spec note accordingly.

[smaug----]

The current behavior says that on untrusted events native code doesn't change anything on the coalesced/predicted lists, no?

(but of course we should clarify the spec, if there is something unclear)