Is there a spec issue for this? Sounds like there isn't an obvious best choice, so discussing with other vendors is a first step.

Just discovered that the spec is precise about it: |button| has to be zero for mousemoves.
https://w3c.github.io/uievents/#event-type-mousemove

So FF is correct here, both Edge & Chrome are wrong. (We matched the Chrome Android behavior to Chrome Windows yesterday on ToT :( )

I think we will file a bug for Edge.

I guess changing Chrome to match the spec (and FF) is reasonable, the risk seems pretty low. If we agree, do you think we need an "intent"?

Unfortunately, due to event enumeration, this is impossible to use count. :(
Can you try and search the HTTPArchive a bit for usage?

Find accesses to |button| from within mousemove handlers would be very tricky from http archive.

I think there might be a way to use-count by adding a custom getter for |button| in MouseEvent.idl.

I fear that neither use counters nor httparchive will be useful here. With use counters, you can never tell how the return value of an attribute is used, and that is all that matters here. Mere access will be tainted by enumeration (for event copying) so isn't really worth measuring in itself.

For httparchive, it's also tricky to find a combination of strings that would be indicative of a problem. Once the change is made and there's a regression, however, one can search for that pattern and perhaps guess at a few others to get an idea of how widespread the problem is.

Do we have any reason to think any particular behavior here is more likely to be web compatible than another, i.e. is there a most conservative approach here?

Will event.buttons accurately reflect which buttons are being pressed? If so, it's probably fine if event.button in that scenario is determined in the same way as when not dragging?

I agree that neither use counters nor httparchive will be useful.

I don't know of any user bug despite the fact that Chrome & Edge don't agree with each other and none follow the spec. So risk is low IMO if we start following the spec.

And yes, event.buttons is speced to cover the chorded buttons case. And browsers seem consistent about it: FF, Edge & Chrome all follow the spec.

The risk of changing behavior in chorded scenarios is IMHO negligable (nobody really codes for chorded button scenarios).  Where there is potential risk is changing button from 1 to 0 in the simple left-button-drag scenario.  I suspect that we could change this alright, although note that MDN does seem to disagree with the spec here: https://developer.mozilla.org/en/docs/Web/Events/mousemove (one rule of thumb we use for "does this need an intent" is "does MDN need updating for this change").

So I guess I'd personally plan to make mousemove.button consistently 0 and err on the side of sending an intent.

The other reasonable alternative is to update the spec to define some specific behavior, but I suspect there won't be much interest in adding complexity to the spec when there's no legitimate use case and no known instances of compat issues.  If we find a site depending on this though, then we should definitely explore that option.

Is there any argument to be made for consistency? When the mouse isn't moving, i.e. for simple clicks, is the behavior of button and buttons interoperable and well spec'd? If so, would the same rules make sense while dragging?

Not moving mouse is not a problem: only mousedown & mouseup matter here, and all browsers seem spec-compliant (even for chorded buttons, in a trivial manner).

Two important notes:

- The observation re Edge was wrong, I clearly messes up something: Edge always has button=0 as per the spec. So this is a chromium-only problem. And this supports our intuition that the risk of fixing that is very low.

- All movement related events in chromium are affected: button should be 0 for all of {mousemove, mouseover, mouseout, mouseenter, mouseleave}. Both FF & Edge are spec-compliant for all of these.

I will send an intent next week.

Just confirmed that on Mac, both Chrome and Safari work perfectly: |button| is always zero for these events.

Looks like the bug has been fixed: I can no longer see |button| != 0 in any of these events, test in Linux, Mac and Windows!  Not sure which change fixed this.

Also fixed on Android.