Control.Layers: stop relying on Browser android and touch properties
#7057
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
johnd0e
force-pushed
the
fix-layers-control
branch
from
f312c26 to
f38b12a
Compare
|
Code from 4e2fe35 replaced with plain It seems that this is not sole place where Lines 205 to 206 in 436430d To do: |
Another alternative: use In year or two pointer events support should be wide enough to adopt this approach. |
johnd0e
force-pushed
the
fix-layers-control
branch
3 times, most recently
from
f086c56 to
5c95d6d
Compare
added 3 commits
January 25, 2021 13:04
- `android` is useless here, as there are a lot of non-android touch devices (including desktop ones)
- `touch` is useless, as mouse can be used on touch-screen too
Now these usecases are covered:
- `mouseenter/leave` are handled on touch devices too
- If Layers control created with {collapsed:false}, and than it collapsed explicitly
[using .collapse() method], it's now possible to expand it back with click.
… touch
Most browsers produce compatibility mouseenter for touch event, but not all,
so we listen for click also.
The problem is that these compatibility events come all in single batch, so
same touch induces expand and then immediate input switching.
To avoid this we temporarily prevent click on layers section.
Note: more straight-forward way would be relying on e.sourceCapabilities.firesTouchEvents,
but atm it has rather low support: https://caniuse.com/#feat=mdn-api_inputdevicecapabilities_firestouchevents
johnd0e
force-pushed
the
fix-layers-control
branch
from
5c95d6d to
e913763
Compare
|
PR improved. |
mourner
approved these changes
Nov 1, 2021
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Control.Layers: stop relying on Browser
androidandtouchpropertiesandroidis useless here, as there are a lot of non-android touch devices (including desktop ones)touchis useless, as mouse can be used on touch-screen tooNow these use cases are covered:
mouseenter/leaveare handled on touch devices tooWith this PR mouse attached to device with touch support behaves as it should: reacts on
mouseover/outevents.But that is up on browser support, e.g. Chrome on android does not produce
mousemove/over/outevents.(But Firefox does)
If Layers control created with
{collapsed:false}, and than it collapsed explicitly[using .collapse() method], it's now possible to expand it back with click.
Fix #6579.
Fix unexpected layer switching when expanding control on touch
Most browsers produce compatibility
mouseenterfor touch event, but not all,so we listen for click also.
The problem is that these compatibility events come all in single batch, so
same touch induces expand and then immediate input switching.
To avoid this we temporarily prevent click on layers section.
Note: more straight-forward way would be relying on
e.sourceCapabilities.firesTouchEvents,but atm it has rather low support: https://caniuse.com/#feat=mdn-api_inputdevicecapabilities_firestouchevents
Related discussions: #6978, #7022.
Test page: https://gist.githack.com/johnd0e/a854f95019bb1a4c1ae909fbc6769d35/raw/pr-7057.html