WOKWI simulation behaves different when using a mouse click than when using keyboard shortcut for wokwi-pushbutton

[GabyGold67]

Describe the bug
In my simulations I found several cases where using the keyboard shortcut to "press" a pushbutton behaves differently than clicking over the pushbutton image. I was working on a much complex project so I had to reduce it pretty much to have a clear idea of what was making the whole system fail. When using the mouse click everything works fine, when using the keyboard the on-screen animation doesn't show the changes in the pin outputs, and sometimes stops the simulation until the key is released (in the most complex cases.

To Reproduce
https://wokwi.com/projects/414436084308322305

Expected behavior
One pushbutton, two leds, a class that models different kind of switches out of a simple pushbutton, the objects might be disabled to ignore the pin input signal. An RTOS timer periodically disables the object to see the behavior of the pushbutton when disabled.
Pressing the pushbutton lights on the green led when the object is enabled, when the timer sets the object as disabled the red led signals it's disabled state and the green led turns off.
Works correctly when pressing the button with the mouse pointer, fails when using the "1" key. The timer is set to change the status every 5000 millisecs, while the change of lighting in the leds is frozen, the timer is still running, as keeping the 1 key pressed will block the animation, but when released the disabled status will keep it's change every 5000 milisecs.

Environment (please complete the following information):

• OS: Windows 10
• Chrome
• Version v132.0.6834.84
• Also under a virtual machine (VirtualBox) running same Windows 10, VSCode up to date with PlatformIO, the WOKWI plugin enabled.

Additional context
For this pruned example it's easy to see the implications, the https://wokwi.com/projects/415018098762515457 project just went berzek...

[Koepel]

Can you try this in the Chrome (or Chrome based) browser ?
When the simulation is running, and if you click on the button to set the focus on the button, does the keyboard "1" then work like the mouse ?

[GabyGold67]

Hi, Thank you for your email. I've just now tried any and every combination I could come up with starting with your suggestion, then alternating the order, then pressing and releasing both the click button of the number 1 (from the top line of keys and from the numpad). And each and every time one of the 1 keys is involved the led animation turn on/off is frozen. I've also tried in a clean notebook with the Edge navigator, which never visited the wokwi page, as an anonymous user... exactly same behavior. I hope this information helps. Anything else you'd wish me to try? Gaby.// El mar, 21 ene 2025 a las 22:04, Koepel ***@***.***>) escribió:

…

Can you try this in the Chrome (or Chrome based) browser ? When the simulation is running, and if you click on the button to set the focus on the button, does the keyboard "1" then work like the mouse ? — Reply to this email directly, view it on GitHub <#951 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATXOBJ5KIMGU265KWBPEYND2L2R3FAVCNFSM6AAAAABVTBTGIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBVGYZTAMRVHE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Koepel]

I did some test, but the difference between keyboard "1" and mouse click is not clear for me. I think that there is a difference when the focus is on the button or not. Perhaps the keyboard gives repeatedly a "1".

Can you make a better test ? It is not clear what the leds do or should do.

[GabyGold67]

Hi, OK, I understand and I'll try to put it as simply as possible for you. Please excuse me but I understand that at least two lines dedicated to what is going on between the pushbutton and the leds. The library is all about converting a pushbutton connected to a pin input (with all the debouncing, deglitching, etc) into an object answering a clean "isOn = true" or "isOn = false". The object has the ability to be disabled, it means no matter if the pushbutton is being pressed and the corresponding signal "isOn = true" is being generated, executing a disable method will set the isOn signal to false, and set a "isEnabled" flag to false. Of course that previously that signal was "isEnabled = true". NOW, in this example setup you've got the pushbutton, you've got the *green led showing the "isOn"* attribute flag state (Off == false, On == true) and the red led showing the "isEnabled" attribute flag (*Off = true, On = false*). That means that the red led turning on means the pushbutton *has been Disabled!* For testing purposes a timer is set to be executed every 5 seconds, toggling the object from Enabled to Disabled and then back. All that said, both leds start off, you press and release the pushbutton and the green led turns on and off as if they were simply wired. After 5 seconds the timer will set the object into *Disabled mode*, turning the red led On to signal the disabling. The pushbutton will become unresponsive until the timer sets the object back into Enabled state. I believe that till now all seems pretty clear and simple. The problem is that embedded behavior of the object dictates that if it enters the Disabled state while it's isOn = true, the *isOn is set to false and the pushbutton goes unresponsive.* Practical testing: while the red led is off, press the pushbutton with the mouse click and keep it pressed. The green led will be turned on and keep it that way. When the timer dictates to disable the object the *red led will turn On*, and the *green led will turn off*. Now try the same actions using the 1 key instead of the click. The timer will keep going, but you would not see the leds change until you release the 1 key, when the leds states will be correctly updated. - First conclusion: *pressing 1 is not having the same effect as pressing with the mouse*. - Second conclusion: after releasing the 1 key and the leds reflect the real situation, the timer will swap the isEnabled flag at the expected time (a multiple of 5 seconds aprox.), meaning *the software simulation kept running* even if the leds state didn't change. In short terms: keep the pushbutton pressed for more than 5 seconds and see the difference when doing so with the mouse and doing it with the 1 key. Sorry for the length. Hope it's much clear now. Gaby.// El mié, 22 ene 2025 a las 9:54, Koepel ***@***.***>) escribió:

…

I did some test, but the difference between keyboard "1" and mouse click is not clear for me. I think that there is a difference when the focus is on the button or not. Perhaps the keyboard gives repeatedly a "1". Can you make a better test ? It is not clear what the leds do or should do. — Reply to this email directly, view it on GitHub <#951 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATXOBJ2ZVV34JW72AMFU4WT2L5FEHAVCNFSM6AAAAABVTBTGIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBWGUZDEOJWGQ> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Koepel]

When I click on the button fast, then the result is the same in all situations.

[GabyGold67]

Hi, You mean when clicking with the mouse and with the "1"? How fast it would be "fast"? Any interaction made from before the "isEnabled" state change and until after the state change would run unnoticed. Now I can reduce my question to *Why holding down the "1" key binded to the pushbutton pauses the leds animation? *And why it doesn't happen when using the intended equivalent of keeping the mouse clicked over it... Have you made any important code change related with my questions the night of the 12/01/2025 or the night after (13/01/2025 night GMT +0200)? I ask as a test done in one of those nights went perfectly right but next morning the problem appeared, I was so burnt out I haven't made enough annotations in my github commits to be sure which one was. Thank you! Gaby.// El mié, 22 ene 2025 a las 14:10, Koepel ***@***.***>) escribió:

…

When I click on the button fast, then the result is the same in all situations. — Reply to this email directly, view it on GitHub <#951 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ATXOBJ3AFKG7IRC3BESMDN32L6DCNAVCNFSM6AAAAABVTBTGIKVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDMMBXGA3TSNRXGM> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[Koepel]

I can not find a consistent way where a mouse click behaves different than the keyboard "1".
The focus of the browser can be on the diagram field, on the button or on something else. That makes a difference for the keyboard, the mouse click makes sure that the browser focus is okay.
It might also depend on the browser, or the settings of the browser or browser extensions.

[GabyGold67]

Hi, I agree, if the focus is not set in the diagram field the keyboard strokes are not sensed at all, that's completely reasonable.
But setting the focus on the field diagram by clicking anyware in it's canvas gets it workin, but you couldn't reproduce the behavior difference...
I don't think about nothing browser related , as the VS Code plugin reproduces exactly the same different behavior!!

I'll try to make some more testing tomorrow, focusing in execution priorities and timers callback executions.

[GabyGold67]

Hi, I finally got some time to check on the simulator different behavior when using the mouse click from the use of the asigned key for a pushbutton and when they DO behave as the same, maybe you can check it from there and identify the source of the differences and maybe make them behave similarly, or make a warning about it.

• The https://wokwi.com/projects/414436084308322305 project presents the behavior difference.
• The https://wokwi.com/projects/421169391724855297 (not visible for the other page visitors) project does not present the behavior difference.

In that second project you'll easily identify the lines added, as they are aftermarked with comments that start with // Added

What was mainly done is to block temporarily the Arduino loop() by using vTaskDelayUntil(). With that addition using the pushbutton click behaves exactly as using the "1" keyboard keys.

It makes it seem like the click and the keypresses are in different priority levels, but you're the ones who know the simulator internals, I just hope this helps you getting rid of the difference that got me completely nuts over the https://wokwi.com/projects/415018098762515457 project simulation.

Please, comment if you've got to notice the difference.

Thank you.

Gaby.//

[Koepel]

I don't know the internals, but I do know that the microcontroller instructions for the Arduino Uno are clock-accurate simulated and the ESP32 has optimizations and runs better when every task has a delay(10);

I tried the two project in the Chromium browser in linux.
In the first project, the leds stay always off. In the second project, they turn on, depending if I keep the button pushed for a long time or just click a few times on it.
In every situation, the behaviour is the same for me. Mouse click or keyboard "1", they behave the same.