runtime.mousedown with both mousebuttons?

I'm setting up the mousedown event like this

	runtime.addEventListener("mousedown", (ev) => doThing(ev));

	onLeftClick() {
		if(rightButtonDown) doThing()
		else doOtherThing()
	}

Update: I'm an idiot, I can just use the mouse plugin lmao

Though I'm a little confused then what the point of the mousedown event in the runtime is.

Mousedown triggers when a button is first clicked. Even if you clicked both buttons at the same time mousedown would be called for each button individually. You can’t directly query the state of a button with the browser so a solution is to just update some variables from mousedown and mouseup events, and then you can look at those variables to access the current button state.

Internally Construct uses pointer events rather than mouse events, and pointer events have a weird quirk where if you hold two mouse buttons, the first button is a pointerdown event, but the second button fires a pointermove event with different buttons. As Construct supports running in a web worker without direct access to input events, it posts pointer events from the DOM to the worker, and synthesises mouse events based on pointer events, but it has the same limitation. So yeah, I guess that's an awkward compatibility difference.

I can think of two possible solutions to this:

1. Use pointer events and watch for the button changes in a pointermove event. Construct adds a non-standard lastButtons property which helps identify new mouse button presses. (Using pointer events also makes it possible to support touch input with the same code.)
2. Turn off worker mode and use the real browser events in the DOM (i.e. document.addEventListener() rather than runtime.addEventListener()).

Thx for the info, not exactly elegant but I'll manage. Is there a chance that this ever gets updated by whoever is repsonsible for this? Who even is responsible for this? I don't wanna turn of worker, so I'll use either option 1 or the mouse plugin.

We're responsible for Construct's firing of mousedown events on runtime, so that part could be fixed. File an issue for it and hopefully I can find some time to look in to improving the compatibility with normal mouse events. As for pointer events themselves, that is all web specifications, and the fact secondary mouse buttons only fire pointermove is by design...

That would be awesome, I added the issue. Fix it whenever you get to it, it's not that much of a pressing issue for me.

As for pointer events themselves, that is all web specifications, and the fact secondary mouse buttons only fire pointermove is by design...

I mean sure, who specifies this though? I never questioned it, but someone has to be behind it. Anyway it seems like a really awkward design choice.

Well, like most web specs it is written by WHATWG or W3C (I forget what the exact relationship between them is), and usually devised by browser makers and interested third parties. The Pointer Events spec was originally written several years ago now. This part of the spec seems to be relevant to how holding mouse buttons work (they call them "chorded button interactions").

I guess conceptually they consider a mouse a single pointer device and so something that can only go down or up once, similar to how a pen device goes down or up (making and releasing contact with the screen) separately to its button press state. But I don't think it's actually very intuitive for a mouse - as developers you just want an event when each button is pressed. It was annoying for developing Construct too.

I see, thx. Sounds like this spec is pretty much set in stone at this point then.