Why 'has dispatched scroll event' depends on whether untrusted scroll events have been dispatched?

[smaug----]

The spec has "If target’s relevant global object is a Window object, event’s type is scroll and its isTrusted is false, set target’s relevant global object's has dispatched scroll event to true."

[npm1]

Oh that's a typo, isTrusted should be true. Before I send a PR to change this, does the rationale for that make sense to you? We don't want to count scrolls performed by the website itself, only scrolls performed by the user.

[smaug----]

scroll events aren't something which occur only because of user interaction. Scroll events tell that something scrollable has been scrolled, it can be because of user using wheel, or scrollbar, or keyboard or touch, or it can happen because of use of some API. So the flag wouldn't answer to the question of "only scrolls performed by the user."

[npm1]

Oh, my bad. Any scroll forced by the use of an API such as window.scroll() would produce a trusted scroll event. So we do want to exclude those as well - any thoughts on whether there is language we can use here? Re isTrusted, we do want to exclude events where isTrusted is false as those can be created and dispatched by the developer at will. But that's not sufficient here since we want to also exclude some scrolls that are trusted...

[smaug----]

So we'd need some flag to tell when user interaction caused some scrolling. Actual scroll event is dispatched way later. What all is counted as user interaction causing scrolling? What if there is <div onmousemove='setTimeout(function_which_triggers_scroll)'>move mouse over me</div>.

Perhaps I don't quite understand the reasoning around scrolling being special. Why for example using wheel to zoom a map isn't treated the same way?

[npm1]

Oh yea I agree that should stop the algorithm too, seems that the spec is just not covering this properly. What about this: we keep a flag that is set when the user performs some interaction which will trigger an event which is not one of mouseMove, mouseEnter, mouseLeave, the touch/pointer counterparts of those, and keyUp.

[smaug----]

enter/leave are triggered by move, so not sure those need to be listed.

I don't quite understand why keyup is special.

[npm1]

A keyup is special because it may be dispatched to a page that was reloaded via Ctrl+R, for example.

[clelland]

43 is related - asking there if there's a reasonable way to signal that a user-initiated scroll has happened, because maybe LCP isn't the right place for that concept.

The original issue appears to have been fixed (#103)

I think the remainder of the issues are being / can be covered by #105