Closed
Description
- I've read the [contribution guidelines][1] and agree with them
I've found a bug and checked that ...
- ... the problem doesn't occur with the default MkDocs template... the problem is not in any of my customizations (CSS, JS, template)... the documentation does not mention anything about my problem... there are no open or closed issues that are related to my problem
Description
Chrome Android, unable to easily change version via the drop-down selector via touch interaction.
Expected behavior
Be able to select version from drop-down on touch device.
Actual behavior
Tapping version selector activates drop-down then navigates to 1st listed version.
Steps to reproduce the bug
- Visit https://squidfunk.github.io/mkdocs-material-example-versioning/latest/
- Tap the version to activate the drop-down selector.
- Page will act as if you selected the top listed (1st item) version.
Package versions / Project configuration / System information
Active release used for project demo site: https://squidfunk.github.io/mkdocs-material-example-versioning/latest/
Metadata
Metadata
Assignees
Projects
Milestone
Relationships
Participants
Activity
squidfunk commentedon Mar 11, 2021
This was already reported on Gitter, thanks for creating an issue. Happy to merge PRs, as I don't own an Android. It works perfectly on iOS and desktop.
polarathene commentedon Mar 11, 2021
Technically I can reproduce on desktop too by just moving mouse over the same location and clicking. I don't have iOS but I guess the touch behaviour is different for a tap which is doing hover/focus on touch, but a click/tap on release(which is now the overlayed drop-down item).
Only solution I'm aware of is handling presentation differently, or some way to detect the touch instead of click to handle that differently. There's official JS browser API for such but I'm not sure if you'd be ok with that approach if it's just for android.
polarathene commentedon Mar 12, 2021
Docusaurus reveals the drop-down below the hover/interaction region, while also highlighting the current version. What do you think about that approach?
squidfunk commentedon Mar 12, 2021
This could be a possible solution. I wanted to unify/simplify the language selector and version selector code anyway, so this might be worth exploring when doing so.
[-]Version selector not touch friendly for mobile devices[/-][+]Version selector not touch-friendly for Android devices[/+]magneticcore commentedon Apr 11, 2021
For information, the language selector doesn't work on Windows Mobile 10, Edge. When it is touched, nothing happens, the selector is not displayed, unlike a select/option html input.
squidfunk commentedon Apr 11, 2021
Interesting.
Does the language selector work for you?I thought I've read version selector. Thanks for clarifying.squidfunk commentedon Apr 11, 2021
Potential fix in 8015c39. I've refactored the focus/hover hierarchy. I can't test on Android or Windows Mobile, as I don't have those devices at my disposal, so it'll be amazing if somebody experiencing the problem could verify it.
squidfunk commentedon Apr 11, 2021
I've updated the versioning example with the latest commit, so you can use it for testing on the devices which are suffering from the error described in the OP. Additionally, navigation between versions has been greatly improved in Insiders. If the current page exists in the version switched to, the user will now stay on the same page without falling back to the homepage:
Ohne.Titel.mp4
polarathene commentedon Apr 11, 2021
I found the selector to have no improvement visiting the example link on Android Chrome. Same issue because the selector appears right over the touch trigger region. If I'm on version
0.1and tap it to change, the selector pops over (hover) and immediately sends me to the overlayed choice0.2.I can use the workaround as before by press and drag finger off the selector region, this keeps it in hover/focus state to then select a choice, but I have to be careful as press and drag in the wrong direction (downwards) will do a pull to refresh action instead due to being at the top of the page. If I press and hold on the same spot I touched instead of drag it's a hover + right click giving options for the
0.2link.Not a good or intuitive UX. I would suggest the selector can reveal itself below the hover region that reveals it. Like how Docusaurus handles it.
polarathene commentedon Apr 11, 2021
positioncan increase thetopto2.5rem, or lose theposition: absolute(losesz-index: 1if that's important, could substitute withposition: relativewhich seems to work too) which doesn't require thetoprule for positioning below the nav bar.I tested these style changes in Firefox with the mobile device sim (Responsive Design Mode:
ctrl+shift+m), although I disabled the "Touch Simulation" it requires the touch click on the selector to reveal it but doesn't mimic the Android Chrome behavior I described above (also verified to occur on Firefox and Firefox Focus browsers on Android).magneticcore commentedon Apr 12, 2021
The selector control (dropdown), no, and I used the selector language configuration with english and french, as described in your documentation.
I checked your example with Windows Mobile 10, still not working. But the burger button works, its menu appears correctly after touching it.
Note: after your last change, a small white rectangle appears beside the version number.
squidfunk commentedon Apr 12, 2021
@polarathene @magneticcore thanks for testing! I'm sorry that I have to loop you in for testing, I'm still trying to put my hands on an Android device in order to reproduce the behavior. Maybe it's the same source of error as for Windows mobile. I've got some ideas on how to fix those problems.
Thanks for your opinion. As @magneticcore points out, the language selector suffers from another problem which implements the solution you proposed (rendering below), so implementing your proposal is likely not the entire fix. Docusaurus also uses the
:hoverevent to display the version and language selectors on desktop and renders those selectors as drop downs hidden in the navigation drawer on mobile:I'd be interested how they handle Chrome tablets (i.e. touch devices with larger screens, so the desktop breakpoint is active), as their solution might suffer from the same problem. Putting the selectors in the drawer circumvents the problem, but that's not a general solution due to different screen sizes.
polarathene commentedon Apr 12, 2021
What problem? I'm confused, you said "rendering below" but all I see are Docusaurus images, @magneticcore stated your version selector test link was not working on Windows Mobile 10 as the selector box was collapsed, sounds like a CSS issue on that devices browser?
Perhaps defaults such as
overflow: autoyou applied are different for them, or you're using some feature that's unsupported/buggy on that device browser? (They did mention Edge earlier, which might be a version before switching to a Chromium base)I proposed CSS changes that did not require
position: absolute(I suggestposition: relativeor just dropping it entirely) ortop, at least from what I can see this correctly positions the selector below the current selection in the navbar.That should be fine for mobile too AFAIK, touching something IIRC gives it focus but also triggers the hover state until you tap elsewhere.
As the finger is released from the display after tapping the version selector, it's behaving like tapping a link, so this behaviour isn't that surprising...?
When I have time, I can make the style modification myself and do a build locally to test against my Android device. I have no Windows Mobile 10 device, the CSS issue there if still prevalent needs to be troubleshooted with @magneticcore .
That surprised me a bit as I thought for sure I had tested it on my phone, but even in landscape orientation and setting the browser to load the "desktop" version, their docs was still detecting/treating my device as mobile... Normally that doesn't happen :/
I haven't looked into their media queries yet, but I'm guessing they're doing something with DPI in addition to viewport width. The breakpoint appeared to be around 1000 pixels when using dev tools in Firefox and adjusting the "device display" width, my phone should have been acting as 1920x1080 roughly with the desktop setting enabled in chrome. (EDIT: Just saw the media query in your screenshot, so I'm a bit puzzled)
I'm not sure why it would suffer though, you use focus/hover to pop-up the selector below the interaction trigger, then you select your choice (which are links in markup). The issue with how this project is doing it is those two things are layered on top of one another and the browser reveals on touch, then "clicks" the link on release (unless you move your finger away and release).
squidfunk commentedon May 30, 2021
bdbd4af fixes the issue after I finally got my hands on an Android device! I've tested on a Samsung Galaxy S9 and iPhone to verify that the issue is fixed and no new issues are introduced. I can't test on a Windows phone, but would kindly ask to open a new issue if this still persists.
squidfunk commentedon May 30, 2021
Released as part of 7.1.6.