runtime.mousedown with both mousebuttons?

Post reply
0 favourites
  • 10 posts

  • I'm setting up the mousedown event like this 

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

    This works as expected for both right- & leftclick until I attempt to hold one and click the other. This should return ev.buttons = 3 except the event is not fired in the first place

    developer.mozilla.org/en-US/docs/Web/API/MouseEvent/buttons

    Using pointerdown doesn't work either. Is this a bug or am I doing something wrong?

    Basically I wanna do is 

    	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.

  • Even if you clicked both buttons at the same time mousedown would be called for each button individually.

    That's the thing though, that doesn't happen. If I click & hold the right mouse button, the left mousebutton will not trigger any further mousedown events and vice versa. Clicking both at the same time has the same issue since one of them is bound to be clicked first unless you happen to get it frameperfect maybe? It seems like this listener is only able to register one button at the same time which seems wrong to me.

    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.

    That's what I'm going to do, but I'll use the mouse plugin for it, because that actually works as I expect it to. That's also what I'm already doing for the keyboard inputs, except I don't have to go through the keyboard plugin for that, I just do: 

    runtime.addEventListener("keydown", (ev) => this.keydown(ev));
runtime.addEventListener("keyup", (ev) => this.keyup(ev));

    and it works. I'd actually prefer this method since it would work exactly the same. The mouse plugin only allows me to use isMouseButtonDown() which internally already tracks the state I suppose but makes it annoyingly inconsistent with how I handle the keyboard inputs. So I'd have to fire a customEvent to register onClick stuff.

  • 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...

  • Try Construct 3

    Develop games in your browser. Powerful, performant & highly capable.

    Try Now Construct 3 users don't see these ads

  • 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.

Post reply
  • 10 posts
Return to board index
Jump to:
Active Users
There are 1 visitors browsing this topic (0 users and 1 guests)