2

When you perform the following sequence of interactions with a mouse on a PC:

  • Left mouse down
  • Right mouse down
  • Left mouse up
  • Right mouse up

The events reported are:

  • Left down
  • Right up

As opposed to the expected:

  • Left down
  • Right down
  • Left up
  • Right up

You can test in the embed:

const d = (sel) => document.getElementById(sel)
const el = d("container");
el.addEventListener("contextmenu", (ev) => ev.preventDefault());
el.addEventListener("pointerdown", (ev) => {
  d("log").innerHTML += `${ev.button} down
`;
});
document.documentElement.addEventListener("pointerup", (ev) => {
  d("log").innerHTML += `${ev.button} up
`;
});
#container{
  padding: 20px;
  border: black 1px solid;
  user-select: none;
}
<div id="container">Click on me</div>
<pre id="log"></pre>

Is this specified in the spec, or is this a situation that's been left to interpretation by vendors?

I shouldn't need to explain why this is a concern, but basically unless there's something I can refer to that specifies this clearly as the intended behavior, then it may be subject to change (or fixing) in the future, and whatever code I write that relies on this (weird) behavior will break horribly.

Update:

According to the spec, which as far as I can tell the most recent version lives here: https://w3c.github.io/pointerevents/

It states,

Pointer Events do not fire overlapping pointerdown and pointerup events for chorded button presses (depressing an additional button while another button on the pointer device is already depressed).

Instead, chorded button presses can be detected by inspecting changes to the button and buttons properties.

Although this explains why the chorded events are eaten up, in the sense that, yes, I can expect the second and subsequent of chorded events to not be delivered, it offers absolutely nothing in terms of how to use this API to get those events, to e.g. know when the second or third chorded buttons get pressed (or released). As far as I can tell from browsers' implementations, all we will ever get are the down and up events for the first-down and last-up buttons, and which buttons those are, and nothing from any of the events that may happen in between.

So far it looks like one has to fall back to old mouse events API to get the full picture.

You can probably get to some sort of an incomplete picture of the state if you read buttons out of e.g. pointermove. But it will be missing a lot of information if the mouse is not moved at the appropriate time. This is an incomplete API, in my opinion.

Steven Lu
  • 41,389
  • 58
  • 210
  • 364

0 Answers0