Small button pressing oddity

[bubblegum]

On mobile, when I press a button in LifeViewer (for example the Undo button or the Catagolue theme button), the button displays a pressed state but doesn’t do anything until I tap somewhere in the LifeViewer screen.
Minor bug that persists throughout the newer builds.

[rowett]

I can't reproduce this. Please let me know which device you are using and which browser.

[wildmyron]

I frequently experience this on mobile with my Android device: Moto G5, Android 8.1.0 and Chrome 76.0.3809.111

As bubblegum reports, I've been seeing this for some time ( I don't believe it's a regression but if it is then it's quite old)

[rowett]

I frequently experience this on mobile with my Android device: Moto G5, Android 8.1.0 and Chrome 76.0.3809.111

Hmm. It works on my Android 7.0 tablet which is also running Chrome 76.

I don't believe it's a regression but if it is then it's quite old

I don't think it's a regression. I haven't changed the menu code recently.

EDIT: a quick bit of Googling found this. Looks like there may be an issue specific to the Moto G5.

[wildmyron]

I frequently experience this on mobile with my Android device: Moto G5, Android 8.1.0 and Chrome 76.0.3809.111

Hmm. It works on my Android 7.0 tablet which is also running Chrome 76.

I don't believe it's a regression but if it is then it's quite old

I don't think it's a regression. I haven't changed the menu code recently.

EDIT: a quick bit of Googling found this. Looks like there may be an issue specific to the Moto G5.

Hmm, that Moto G5 issue seems pretty serious. I don't think that's at play here because touch events in general are working.

In any case I think I understand what's happening here. If there's any movement of my finger during the tap on the buttons, then the bug reported here is reliably triggered. I suspect that very slight finger movements during buttone taps are also triggering this bug a lot of the time, and other times I'm apparently reliably tapping without any movement. Is the same behaviour seen on other devices? I'm not sure how that kind of thing should be dealt with in general, but it seems like it would be a fairly common problem / distinction that needs to be made between different events.

In case it's relevant, I should also mention that I've noticed on another app which has differing behaviour for "double tap and drag" vs. "tap and drag" that I frequently trigger the "double tap and drag" event when I intend to "tap and drag". This is using the same Moto G5 device. This suggests to me that my device is more sensitive / less reliable at distinguishing touch events.

[rowett]

In any case I think I understand what's happening here. If there's any movement of my finger during the tap on the buttons, then the bug reported here is reliably triggered. I suspect that very slight finger movements during buttone taps are also triggering this bug a lot of the time, and other times I'm apparently reliably tapping without any movement. Is the same behaviour seen on other devices? I'm not sure how that kind of thing should be dealt with in general, but it seems like it would be a fairly common problem / distinction that needs to be made between different events.

I'll take another look at the menu event handling code.

To register a "click" two things need to be true:

1. When the tap starts (finger on screen) it is over a button
2. When the tap ends (finger is removed) it needs to be over the same button

It doesn't matter if you move your finger between steps 1 and 2 even if you move outside the button. As long as your're back over the control when the tap finishes (step 2) it should click.

Do you have any settings turned on your phone that effect how taps are handled?

[wildmyron]

To register a "click" two things need to be true:

1. When the tap starts (finger on screen) it is over a button
2. When the tap ends (finger is removed) it needs to be over the same button

It doesn't matter if you move your finger between steps 1 and 2 even if you move outside the button. As long as your're back over the control when the tap finishes (step 2) it should click.

I am unable to discern any difference in the way I tap buttons which would distinguish when it does and doesn't work properly, but at the default zoom the buttons in the Lifeviewer window are fairly small on my device - comparable to the area of my finger tapping the screen - so I suppose it is possible that sometimes the tap end position is outside the button. I feel like tapping the controls is more reliable when I zoom in, but I don't have any empirical evidence for this.

Do you have any settings turned on your phone that effect how taps are handled?

I'm not aware of having changed any of these settings from the defaults. The only relevant setting I can find is:
Accessibility -> Touch & hold delay -> Short

And apparently I have changed the following Chrome setting:
Accessibility -> Text scaling -> 110%

---

After a bit more testing I don't think moving my finger is the problem. Here are a few event sequences (with results in brackets)

- Open pattern in Lifeviewer
- "Tap start" on Play button (Play button is highlighted green)
- "Drag" to somewhere in the centre of the viewer
- "Tap end" (Play button becomes unhighlighted)

[Example when tap fails]
- Open pattern in Lifeviewer
- "Tap" on Play button (Play button highlights green)
- "Tap" somewhere in the centre of the viewer (Play button changes to pause and is highlighted blue, pattern starts playing)

[Example when tap works]
- Open pattern in Lifeviewer
- "Tap" on Play button (Play button changes to pause and is highlighted green, pattern starts playing)
- "Tap" somewhere in the centre of the viewer (Pause button is highlighted blue)

[Double tap]
- Open pattern in Lifeviewer
- "double tap" on play button [as fast as possible] (Play button briefly changes to pause and back to play, is highlighted green, pattern is evolved for a small number of generations)

Combined with the double tap behaviour I see in the other app I mentioned, this suggests to me that what is happening is Lifeviewer is receiving a double tap event sometimes, even though I'm intending to make a single tap - and this is causing play to be started and then paused again before the pattern has been evolved.

[wildmyron]

After a bit more testing I don't think moving my finger is the problem. Here are a few event sequences (with results in brackets)

<snip>

Combined with the double tap behaviour I see in the other app I mentioned, this suggests to me that what is happening is Lifeviewer is receiving a double tap event sometimes, even though I'm intending to make a single tap - and this is causing play to be started and then paused again before the pattern has been evolved.

Hmm, my analysis seems to be way off here - it doesn't make any sense that the effect of the tap on the play button could manifest when tapping somewhere else on the viewer. Also, I forgot that the same button pressing issue happens with the Step forward and Step back buttons. In these cases (and other buttons where it's also occasionally an issue) when the single tap fails to work properly there's no indication that there was a double tap event. Instead the effect is though the "tap start" event is registered but the "tap end" event is not. Then when I tap elsewhere the "tap end" event seems to register - but in the correct place. Sorry for adding confusion to this issue.

[rowett]

I've modified the way LifeViewer handles touch events. Please try the just released
Build 395 and let me know if it's any better.

[wildmyron]

I've tested the new build and still occasionally see the buggy behaviour (about the same frequency as before). There is a difference in what happens though - I no longer see the tapped button highlighted green when the tap event is "stuck".

I'm quite prepared to attribute this to quirky behaviour on my device (and bubblegum's device too).

[rowett]

I've tested the new build and still occasionally see the buggy behaviour (about the same frequency as before).

OK thanks for testing. I wasn't really expecting much of a difference since I couldn't see anything particularly wrong with the original code.

There is a difference in what happens though - I no longer see the tapped button highlighted green when the tap event is "stuck".

Yes this I did change. Green is used to show when the mouse pointer is over a control you can interact with.

For touch devices this doesn't make much sense since if you're touching the screen you normally can't see the controls and once you stop touching you're not over any control. So now for touch events you only get green whilst you're actually interacting with the control.

I'll do a little more digging on the touch events.

[rowett]

I've made some further updates to the touch event handler.

Please try this build from your mobile device and let me know if it helps!

[wildmyron]

I've made some further updates to the touch event handler.

Please try this build from your mobile device and let me know if it helps!

I still see the same behaviour with build 397.

[bubblegum]

I've made some further updates to the touch event handler.

Please try this build from your mobile device and let me know if it helps!

No, this new build put the first button back, like I was trying to go back one tick, so I pressed the back one tick button, it turned green and then turned colorless and did nothing, then I pressed it again and it went back two ticks. Oof.
(device is iPad Air 2, still works, kind of)

[wildmyron]

Deleted.

@bubblegum: what version of iOS are you running and which browser/version?

Edit: I am occasionally able to reproduce this on desktop, but it's much more sporadic. Dell Latitude 7480 with touchscreen, Win 10, Firefox v60.9.0esr (64-bit) and also Chrome v76.0.3809.132 (Official Build) (64-bit). I reproduce with the following steps:

-0- Open https://lazyslug.com/lifeview/plugin/viewer.html
-1- Refresh the page
-2- Tap Reset
-3- Tap Play
-4- Repeat from -1-

About 1 out 10 - 20 times I do this the viewer won't start playing and then when I tap anywhere else on the viewer playback will start. Like for mobile I can't reliably discern any difference in the way I tap buttons that causes the bug to happen.

[rowett]

About 1 out 10 - 20 times I do this the viewer won't start playing and then when I tap anywhere else on the viewer playback will start. Like for mobile I can't reliably discern any difference in the way I tap buttons that causes the bug to happen.

The plot thickens...

Please try this build and let me know what you find. During taps it will display on the screen debugging information:

1. start <id> <x> <y>
2. move <id> <x> <y>
3. end <id> <x> <y>

When you see the bug let me know what debugging info is displayed. Thanks!

[wildmyron]

Please try this build and let me know what you find. During taps it will display on the screen debugging information:

1. start <id> <x> <y>
2. move <id> <x> <y>
3. end <id> <x> <y>

When you see the bug let me know what debugging info is displayed. Thanks!

On my laptop I found it pretty hard to reproduce with build 398. (Although I suspect this is probably coincidence.) With every tap I see the id increment. On the one occasion the bug occurred, the debug info displayed was:

Code: Select all

start 1154 499, 774

end 1154 498, 775

On my mobile device the id is always 0. I can still reproduce fairly frequently and there doesn't seem to be any obvious difference in the debug info reported. Here are several reports after tapping the play button when the bug occurred:

Code: Select all

start 0 504, 839

end 0 504, 839

Code: Select all

start 0 507, 834

end 0 507, 834

Code: Select all

start 0 510, 831

end 0 510, 831

[rowett]

Thanks for the feedback.

I've added further debug info to this build. After the touch events it should tell you which button or list was clicked on.

Please would you try again and let me know what it says?

[wildmyron]

I've added further debug info to this build. After the touch events it should tell you which button or list was clicked on.

Please would you try again and let me know what it says?

Here are a few copies of the debug output from taps on the Play button where it failed to start playing (and subsequently started when tapping elsewhere). I've included the output after the second tap as well, just in case.

Code: Select all

start 0 505, 847
end 0 505, 847
list click 117/3 355, 520

start 0 428, 475
end 0 428, 475

Code: Select all

start 0 498, 827
end 0 498, 827
list click 117/3 355, 520

start 0 332, 520
end 0 332, 520

Accidentally moved my finger during this tap

Code: Select all

 start 0 508, 850
move 0 510, 848
end 0 510, 848
list click 117/3 355, 520

start 0 306, 478
end 0 306, 478

An example from when a tap on the play button worked

Code: Select all

start 0 507, 836
end 0 507, 836
list click 117/3 355, 520

[rowett]

Here are a few copies of the debug output from taps on the Play button where it failed to start playing (and subsequently started when tapping elsewhere). I've included the output after the second tap as well, just in case.

Code: Select all

start 0 505, 847
end 0 505, 847
list click 117/3 355, 520

start 0 428, 475
end 0 428, 475

Thanks again for the information.

What was the timing between the lines in the debug output appearing? I've updated this build to add timing details.

From the output above the sequence suggests the button was clicked after the first tap, and the second tap (which wasn't on the button) did nothing.

[wildmyron]

From the output above the sequence suggests the button was clicked after the first tap, and the second tap (which wasn't on the button) did nothing.

The sequence is correct, but the actual evolution of the pattern doesn't start until the second tap. Here's a screencap:
https://drive.google.com/file/d/1-dgKoY ... p=drivesdk

[rowett]

The sequence is correct, but the actual evolution of the pattern doesn't start until the second tap. Here's a screencap:
https://drive.google.com/file/d/1-dgKoY ... p=drivesdk

That's super helpful. Please try this build.

[wildmyron]

Please try this build.

I tried to reproduce with that build for several minutes on my mobile device and didn't see the bug at all.

Does this mean you made a change which has hopefully fixed it?

[rowett]

I tried to reproduce with that build for several minutes on my mobile device and didn't see the bug at all.

Does this mean you made a change which has hopefully fixed it?

Yes, many thanks for your help!

This has now been released in Build 398.