Need a new DOM concept for user-driven events rather than using `isTrusted`

[sefeng211]

We have been using the isTrusted attribute to check if the event comes from a user interaction, however this attribute only indicates that the event was dispatched by user agents.

For instance, user agents fire a scroll event with isTrusted=true for scrollLeft, and apparently we don't want to stop creating LCP when we see this scroll event.

So we need a new concept that we can use in the spec.

[yoavweiss]

Thanks for filing this, @sefeng211!

/cc @noamr @domenic for thoughts on the above. Any objections to adding such a concept?

[yoavweiss]

@domenic The navigation API seems to have a user initiated concept that may be close in spirit to what we want here. Do you think it'd make sense to pull that into DOM and generalize it beyond navigations?

[domenic]

I don't think that concept (defined more fully here) is really related to what you're looking for here.

[noamr]

Looking at the definition of the scroll event, I'm not sure a new concept is needed. Perhaps that spec can be modified to preserve in the list of pending scroll event targets whether the event was user-initiated or programmatic, and LCP can refer to that.

Are there other places where this is needed?

[yoavweiss]

The same concept is something we need for has dispatched input event, for "click", "mousedown" and "keydown".

We could create something specific for each one of these events (or two concepts, one for scroll and one for input).

[noamr]

Seems like isTrusted would be the right mechanism, except it doesn't send the right value for click. Doesn't say in the spec whether isTrusted is supported for scrolle vents. So I guess you could use isTrusted where it's supported and special-case click.

[noamr]

... using isTrusted in this way seems similar to how it's used for activation.

[domenic]

The special behavior of isTrusted for click(), although theoretically impure, is probably still what you want for cases like this. That is, we set isTrusted to false for both click() and dispatchEvent(), reserving isTrusted true for "actual" clicks.

[noamr]

The special behavior of isTrusted for click(), although theoretically impure, is probably still what you want for cases like this. That is, we set isTrusted to false for both click() and dispatchEvent(), reserving isTrusted true for "actual" clicks.

Ah got it, thanks for the clarification. So isTrusted sounds perfect but you'd want to make sure it applies to scroll events or special-case it in the wording. Perhaps if it doesn't it would be valuable to propose to change that in CSSWG

[yoavweiss]

At least for scrolling, isTrusted is not good enough, as e.g. setting scrollLeft triggers a trusted event, but shouldn't stop LCP entries from being emitted. I'm not sure if there are ways to trigger input events (beyond click()) that are UA trusted, but not user initiated.

[noamr]

At least for scrolling, isTrusted is not good enough, as e.g. setting scrollLeft triggers a trusted event, but shouldn't stop LCP entries from being emitted. I'm not sure if there are ways to trigger input events (beyond click()) that are UA trusted, but not user initiated.

So perhaps we can add a boolean to scroll events in particular (an isACTUALLYTrusted sort of thing, perhaps isScriptInitiated), and use isTrusted for everything else?