pointerlockchange is cancelable, breaking the processing model

[therealglazou]

This is a copy of my objection to the Pointer Lock spec, as requested by Xiaoqian Wu during W3C TPAC:

I think there is a big issue in the model because first paragraph after the Note in section 5.1 says if the pointer is already locked in the same document, the pointer lock target is updated and an event fired. But the event can be cancelled (the new events are not specified as not cancelable by this spec) by the event handler in which case the pointer lock target should not be updated beforehand. Furthermore, it's necessary to have the event itself have a reference to the new element requesting the pointer lock in order to be able to determine if the event should be cancelled or not (so that's a change for section 4). Similarly, an initial pointerlockchange event can be cancelled by the handler.
Another way to fix this issue is to make the pointerlockchange event not cancelable.

[annevk]

Events cannot be canceled by default so if it's not specified one way or another I don't think there's a problem since the default would apply.

(Also, even if the event were defined as cancelable, unless the specification did something with the canceled flag (and defined that) it would be effectively a no-op.)

[scheib]

Thanks for the response @annevk, does that satisfy you @therealglazou or do you believe a spec change is needed?

[therealglazou]

Right @annevk and @scheib , the default cancelable attribute in EventInit dictionaries is false but nothing in the spec says the event is never cancelable so it's still possible to create programmatically such an event with the cancelable flag to true in the eventInitDict and dispatch it. The fact the spec says nothing about the handling of the canceled flag is an ambiguity in the spec and I see it as an underspecification that could lead to issues on the users' side and even possibly on the browsers' side. If all brower vendors agree these events should never be cancelable/canceled, its should be in the spec. So, yes, I still think a spec change is needed. It's a cheap change and IMO a very useful clarification.

[annevk]

Creating and dispatching a synthetic event doesn't have side effects (unless it's named "click") so I don't think that is actually a problem.

[scheib]

@therealglazou, does this work?
pull request diff
preview

[annevk]

@scheib FWIW, I think that'd be a bad change. We don't define those kind of things for other events either. And just adding boilerplate everywhere doesn't seem like an improvement.

[LJWatson]

If I understand this correctly it feels like an editorial issue. That said, it would help if we had tests that demonstrate this implicit behaviour - @scheib do we have such a thing?

[scheib]

We do not have tests for synthetic events with the cancelable flag set, and handlers attempting to prevent the events.

I don't really see a concern here @therealglazou. Attempting to create a synthetic event as cancelable and then prevent it doesn't seem meaningful in general.

Web developers should not have an expectation that creating a synthetic fullscreen or pointer lock event will cause the browser to enter or exit those modes. I believe this is what @annevk is referring to when saying "Creating and dispatching a synthetic event doesn't have side effects (unless it's named "click")".

Going beyond that, and then expecting the synthetic events to be cancelable only continues to be non-meaningful, but not even based on an initially meaningful action.

I must say that I'm agreeing with @annevk that there seems little reason to address this in all specifications. Just as not all specifications should need to state that no action is taken if a synthetic event is created.

When you state "The fact the spec says nothing about the handling of the canceled flag is an ambiguity in the spec and I see it as an underspecification that could lead to issues on the users' side", I'm curious what examples could come to mind?

[therealglazou]

Withdrawing my objection.