Between the two there were some refactors to the plumbing of registered event listeners.
It changes the behavior so the menu's touch listener runs even though it wasn't registered at the time of the touch event. My guess is it has to do with the menu being called from within the touch listener that first act on the event.
What tripped me up before was, the change/bug only seem to happen when elapsed_t was loaded in with a standard load call. If fastloaded to (e.g. going back from the launcher) it didn't happen.
Espruino is a JavaScript interpreter for low-power Microcontrollers. This site is both a support community for Espruino and a place to share what you are working on.
Weird. Now I flashed 2v24.118 again and now I get the bug there as well... 😂
Edit:
Now I narrowed it down...
2v24.89 doesn't have the changed behavior:
https://www.espruino.com/binaries/travis/67da4057cb4cccdd15176cfdec4bc4341ac6058a/
... while 2v24.93 does:
https://www.espruino.com/binaries/travis/133933b82ae5a94b8bd8928ee0f7d8d15e962d47/
Between the two there were some refactors to the plumbing of registered event listeners.
It changes the behavior so the menu's touch listener runs even though it wasn't registered at the time of the touch event. My guess is it has to do with the menu being called from within the touch listener that first act on the event.
What tripped me up before was, the change/bug only seem to happen when
elapsed_t
was loaded in with a standardload
call. If fastloaded to (e.g. going back from the launcher) it didn't happen.The relevant commits: