Piggy Bank touch button behavior on Win 10

[KatieWoe]

Test device Dell

Operating System Win 10

Browser IE and Chrome

Problem description Found while testing https://github.com/phetsims/number-line-integers/issues/69. The behavior of the add/remove coins buttons seem to be a bit buggy on touch devices. The IE behavior is particularly odd. However, since we do not support IE on Win 10, that aspect may not be worth pursuing. When you hold the button down and move your finger off the button, one of two things can happen. On IE the button loses all 3D effects for a time. On other devices the button can look undepressed even when behaving as though it is (it should be, so behavior is correct I believe).

Steps to reproduce

1. Use touch to depress one of the buttons
2. Still holding down, move your finger off the button.

Visuals IE: Chrome:

Troubleshooting information: !!!!! DO NOT EDIT !!!!!

Name: ‪Number Line: Integers‬ URL: https://phet-dev.colorado.edu/html/number-line-integers/1.0.0-dev.10/phet/number-line-integers_all_phet.html Version: 1.0.0-dev.10 2019-12-11 16:22:53 UTC Features missing: touch, fullscreen Flags: pointerEnabled, msPointerEnabled, pixelRatioScaling User Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; Trident/7.0; Touch; .NET4.0C; .NET4.0E; .NET CLR 2.0.50727; .NET CLR 3.0.30729; .NET CLR 3.5.30729; Tablet PC 2.0; Zoom 3.6.0; rv:11.0) like Gecko Language: en-US Window: 1536x750 Pixel Ratio: 2.5/1 WebGL: WebGL 0.94 GLSL: WebGL GLSL ES 0.94 Vendor: Microsoft (Internet Explorer) Vertex: attribs: 16 varying: 15 uniform: 512 Texture: size: 16384 imageUnits: 16 (vertex: 16, combined: 32) Max viewport: 16384x16384 OES_texture_float: true Dependencies JSON: {}

[jbphet]

On IE the button loses all 3D effects for a time.

I'm not able to duplicate this on my Dell XPS Win 10 machine, IE Version 11.1184.17134.0.

[S]ince we do not support IE on Win 10, that aspect may not be worth pursuing.

Given that it doesn't seem to happen on my machine, and it a pretty unlikely use case (Internet Explorer on a touch device), and doesn't seem to have significantly detrimental effects on the operation of the sim, I feel that this is indeed not worth pursuing further.

On other devices the button can look undepressed even when behaving as though it is (it should be, so behavior is correct I believe).

Two things on this:

1. The appearance changes to undepressed when the touch is no longer on top of it by design, since physically it can't be pressed if there is nothing pressing it. The mouse behavior is the same. I just tested this a simple HTML button in https://www.w3schools.com/html/tryit.asp?filename=tryhtml_form_submit, and the "Submit" button also becomes undepressed if it is pressed via a touch event and then the finger slides off of the button (on my Dell Win 10 on Chrome). Other aspects of the behavior are somewhat different.

2. I don't understand the meaning of the parenthetical statement at the end of this sentence. Are you saying that you believe the current behavior is correct, or that it would need to stay depressed for the behavior to be correct?

I just tested the behavior of the up/down buttons used in level 2 of the Build an Atom game, and the behavior appears to me to be the same as what is being described for the Bank Scene buttons. All in all, this seems like a non-issue to me. @KatieWoe - if you disagree with my assessment, please assign to @ariel-phet for further discussion. Otherwise I think it should be closed.

[KatieWoe]

I did notice it can occur with mouse (done on IE). I do think this is still odd so @ariel-phet could you take a look?

[ariel-phet]

@KatieWoe to me this behavior is correct. What I am seeing is the following:

1. Press my finger on the button
2. Slide my finger off the button without having lifted it off the screen
3. The button will no longer be "visually" depressed but the action corresponding to its depressed state will continue to occur until I lift up my finger

I see the same behavior with a mouse.

These behaviors are designed and intentional. Once pressed the button continues to have the "firing" action until the "up" event of the pointer is registered (finger off the screen or mouse button undepressed). @jbphet pointed out, the visual behavior of the button is a bit separate, once you have slid off, it will pop back up, even though it may still be responding to a pointer down event.

I understand how this behavior could feel a bit inconsistent, but in any normal use case (for instance finger moving slightly off the button, but still held down) it will almost assuredly be what the user intends. I think it is best to view the visual behavior of the button as reflecting whether the pointer event is happening on the button or not.

Assigning back to @KatieWoe to close.