search

processing / p5.js

p5.js is a client-side JS platform that empowers artists, designers, students, and anyone to learn to code and express themselves creatively on the web. It is based on the core principles of Processing. http://twitter.com/p5xjs —
http://p5js.org/
GNU Lesser General Public License v2.1
21.48k stars 3.29k forks source link

mouseIsPressed gets stuck on true #5524

Open ghost opened 2 years ago

ghost commented 2 years ago

mouseIsPressed gets stuck on true.

Heres a code example here: https://editor.p5js.org/Jstodd/sketches/1voaDYszt

Try clicking on the screen. After the alert pops up (also happens with console in some cases) mouseIsPressed will be stuck on true.

If you hover your mouse over a button youve created, its going to set it off. This is bad for UX and security. it is also not expected behavior.

Quick fix: Im able to fix it for myself, by setting mouseIsPressed = false in my looped code, that way it force resets it to false every frame.

Image of bug: mouseIsPressedBug

I am using Ubunto 20.04 LTS Linux, and Brave Browser (Version 1.33.106 Chromium: 96.0.4664.110 (Official Build) (64-bit))

My browser settings are normal, no strict mode or anything. And generally Brave should run smooth like Chrome because its chromium based and kept up-to-date.

reejuBhattacharya commented 2 years ago

I have been trying to reproduce the bug on other browsers and observed the following:

On Firefox, I could not reproduce the bug and the code ran as expected. image

However, on Chrome, the code deviated from its expected behavior. After the first mouse-click and after the alert box was displayed, mouseIsPressed gets stuck to true. However, on subsequent clicks, the behavior reverts to normal. In the below picture, you can see the first 'true' last for 285 counts where it was stuck, but subsequent 'true' values only last for a short count, as is expected. image

stampyzfanz commented 2 years ago

As shown by this sketch: https://editor.p5js.org/stampyzfanz/sketches/BEh2Ti-3s, the mouseup event is not triggered when an alert box is closed and the cursor is lifted (at least on my browser, Chrome). By commenting out the alert call, one can validate that it is normally triggered as expected. Internally, p5.js changes mouseIsPressed on the mousedown and mouseup calls.

Your quick fix means that mouseIsPressed is only true for a single frame, which is not what it is designed for. A solution is to poll the body (and maybe its descendants) every frame to determine if an element has the psuedo-class "active". I imagine this could be implemented as a getter cached once a frame so it is it only computed for frames where it is accessed. SO source for my quick fixes Code demonstrating my suggested fixes.

limzykenneth commented 2 years ago

@stampyzfanz I would prefer not to tie the behaviour of mouseIsPressed to the animation loop, one is because it is more idiomatic for it to be controlled by the mouse events which usually is not in sync with the animation loop; two is because if the user does not run the animation loop (with noLoop()) but is using mouseIsPressed in some other places outside of draw(), the value will not be updated.

proxycase commented 2 years ago

I wonder about accessibility concerns, but I'm wondering if checking for mouse pressed condition on a canvas or window onBlur event would be necessary to catch this edge case.