[iOS] QSelect doesn't trigger the keyboard when using Autocomplet on more than 2 chars

[Bosphoramus]

What happened?

This bug was fixed in Quasar v1 but its broken again in Quasar v2, more info here, on the latest comments:
#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:
#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:
#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:
#6491

[github-actions]

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. 👏

[Bosphoramus]

Made this issue without reproduction or description following @pdanpdan advice on this issue:
#6491

[pdanpdan]

BTW, for me on iOS all examples with filtering do not show the keyboard (both safari and chrome)

[xaxoxavi]

Same error

[maven1129]

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.

[RobbeVorsselmans]

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.

[miroshnichenkoYaroslav]

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

[robopeter]

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:
  • The 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).
• I suspect the problem is that Safari on iOS is very particular that focus events need to be triggered by human input for the keyboard to pop up and the fact that we're queueing this event means that iOS thinks it's not a human giving focus (hence the keyboard doesn't pop up).
• waitFlags is populated in addFocusWaitFlag in focus-manager.js which is called by:
  • showPortal in use-portal.js
• Commenting out the call to 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)

[wmsoftware-de]

Problem still exists. Any solution? Commenting out the call to addFocusWaitFlag in use-portal.js does not help and might have side-effects.