Open Bosphoramus opened 1 year ago
Hi @Bosphoramus! 👋
It looks like you provided an invalid or unsupported reproduction URL. Do not use any service other than Codepen, jsFiddle, StackBlitz, Codesandbox, and GitHub. Make sure the URL you provided is correct and reachable. You can test it by visiting it in a private tab, another device, etc. Please edit your original post above and provide a valid reproduction URL as explained.
Without a proper reproduction, your issue will have to get closed.
Thank you for your collaboration. 👏
Made this issue without reproduction or description following @pdanpdan advice on this issue: https://github.com/quasarframework/quasar/issues/6491
BTW, for me on iOS all examples with filtering do not show the keyboard (both safari and chrome)
Same error
Same - Autofocus doesn't work on iOS. It also doesn't work on the popup in dialog option. Loading a page with autofocus enabled does not focus the field on iOS, and doesn't pop the keyboard. Android focuses (blinking cursor) and keyboard pop on page load.
The problem still persists. When I activate Q-select with use-input the menu opens, but the input field is not selected and thus the keyboard not shown. This happens only in iOS, not on my desktop.
Same error, in the case when q-input has autofocus, then keyboard covers q-input if the text field is below the height of the keyboard
I don't really know what I'm doing, but this bug is blocking the release of my app so I've started to dig into it some.
From what I can gather:
showPopup
in QSelect.js
calls:
focus
method in use-field.js
which calls:addFocusFn
in focus-manager.js
.addFocusFn
does two different things depending on if waitFlags
has a non-zero length or not. In the mobile case it's non-zero which adds the focus function to a queue (presumably to be callled later). waitFlags
is populated in addFocusWaitFlag
in focus-manager.js
which is called by:
showPortal
in use-portal.js
addFocusWaitFlag
in use-portal.js
makes the keyboard properly pop up for me in the "Select Part 7 Text" test in the "ui" dev project (this test is broken in an un-modified build).My question at the moment is... what's the point of the waitFlags
? I'd suspect they serve a useful purpose, but it's hard for me to change their behavior (e.g. don't use them on safari, or ever) without knowing what might break without them. Thanks!
PS: I don't think this bug needs the "bug/0-needs-info" label... it repoduces in the built-in test project)
Problem still exists. Any solution? Commenting out the call to addFocusWaitFlag in use-portal.js does not help and might have side-effects.
What happened?
This bug was fixed in Quasar v1 but its broken again in Quasar v2, more info here, on the latest comments: https://github.com/quasarframework/quasar/issues/6491
What did you expect to happen?
This bug was fixed in Quasar v1 but its broken again in Quasar v2, more info here, on the latest comments: https://github.com/quasarframework/quasar/issues/6491
Reproduction URL
https://codepen.io
How to reproduce?
This bug was fixed in Quasar v1 but its broken again in Quasar v2, more info here, on the latest comments: https://github.com/quasarframework/quasar/issues/6491
Flavour
Quasar CLI with Vite (@quasar/cli | @quasar/app-vite)
Areas
Components (quasar)
Platforms/Browsers
No response
Quasar info output
No response
Relevant log output
No response
Additional context
This bug was fixed in Quasar v1 but its broken again in Quasar v2, more info here, on the latest comments: https://github.com/quasarframework/quasar/issues/6491