Synthetic click activation steps should state whether the event is composed or not

[rniwa]

To run synthetic click activation steps or more broadly the definition of firing a click event should clarify when if ever the event is fired with composed flag set to true.

Also, the definition of initializing an event should take composed as an argument.

As things stand, the specifications are extremely unclear about when & how this flag is set.

[rniwa]

@annevk @domenic @hayatoito @bzbarsky @travisleithead

[rniwa]

Note that the last test case in event-composed.html tests that composed flag is set to true when a synthetic click event is fired via HTMLElement.prototype.click.

[annevk]

"initialize" is used to define initEvent() and similar legacy methods. It doesn't need updating. Just use event constructors (which do take a composed dictionary member in the second argument).

I agree that we should clarify "click" however. And I think it should be composed because it's user input. We mainly considered UI Events and forgot HTML dispatches some of those too.

[rniwa]

Well, UI events already spec that user-initiated click is composed. The question is whether synthetic click event fired by HTMLElement.prototype.click should be composed or not.

[annevk]

We also fire a synthetic click for keyboard-initiated "clicks", no? In any event, I think they should be composed.

[hayatoito]

An UI Event which is not dispatched via new Event("", {...}) should be composed, I think.

In other words, if users do not have any chance to specify whether the event is composed or not via an explicit parameter, it should be considered composed.

[rniwa]

In other words, if users do not have any chance to specify whether the event is composed or not via an explicit parameter, it should be considered composed.

That's a pretty good easy-to-follow principle!

[annevk]

But that only applies to non-synthetic UI events, right?

[hayatoito]

Ah, yeah. I have found that element.click() does not dispatch trusted events.
It is a synthetic event, but users do not have a chance to specify it is whether composed or not.

We have a kind of contradiction. :(

[rniwa]

That's okay. The principle you stated in #578 (comment) doesn't concern trusted-ness at all. The only question is whether author script can specify composed or not. It can't so it must be composed unless we're adding a new option to click() e.g. click({composed: true}).

[annevk]

How do you tell something is a UI event? But yeah, given what @smaug---- said elsewhere about his views on click() it would not make sense for it to use composed.

[smaug----]

Not sure how my comment elsewhere about click() applies here. Hadn't thought about .composed. I don't have strong opinion on this. #578 (comment) doesn't sound bad, so click() would dispatch .composed set to true.

[annevk]

Do we still want to flip this? What do implementations do and do we have tests? HTML still ends up setting composed to false by not talking about it.

[annevk]

Ah okay, we have a test at https://github.com/w3c/web-platform-tests/blob/master/shadow-dom/event-composed.html#L76 as pointed out earlier.

[annevk]

WebKit fails that test and Chrome passes it. It seems that everyone thinks it should be composed so I'll fix that.

[rniwa]

The implementation bug in WebKit is tracked as https://bugs.webkit.org/show_bug.cgi?id=170211.