Double-tap on select/multi-select inputs on mobile triggers unwanted tooltip

[AndrejNemec]

Dependencies check up

• I have verified that I use latest version of all @mantine/* packages

What version of @mantine/* packages do you have in package.json?

7.8.0

What package has an issue?

@mantine/core

What framework do you use?

Vite

In which browsers you can reproduce the issue?

All

Describe the bug

I am encountering a bug on mobile devices related to select/multi-select inputs. When I double-tap a select input that does not allow text entry, a mobile tooltip is triggered, offering autofill/paste options. This behavior is quite annoying for the users.

It seems that the issue is caused by an internal input element within the selector (mantine-Select-input), which is set to readonly. I have attached a video to demonstrate the issue.

select_bug.MP4

If possible, include a link to a codesandbox with a minimal reproduction

No response

Possible fix

Replace the input element with another element.

Self-service

• I would be willing to implement a fix for this issue

[Prasiddha22]

@rtivital I had made some changes and made a PR that resolved this issue. You can see that in the PR description that I had created. But that implementation failed some test cases and I closed the PR for now. Can you please check it once at your convenience? If that felt the right direction, we can further continue working on that.

[minosss]

Em... I have tried many methods. Clicking on a focused input field that is read-only on a mobile device still brings up autofill.
#7012 also has the same problem.

[tejas-1206]

I tried reproducing this issue on multiple Android devices as well as across multiple browsers (chrome, brave), but could not reproduce this issue.

Can you provide info on the device and browser that you are facing this issue on ?

Can you also confirm if you are facing the same issue on non-safari and non-apple devices as well?

If yes, then this is probably a browser or OS level issue. It can also be that this issue is safari specific or even an apple device specific issue (since your screen recording seems to be from an iPhone). So, it's better to strike out other possibilities that are not in control at a UI library layer (mantine, in this case).

[AndrejNemec]

@tejas-1206 This issue occurs on all browsers on iOS devices. It is likely because all browsers on iOS use Safari’s WebKit engine under the hood, but I am not entirely certain about this claim. Importantly, the issue does not happen with other frameworks implementing custom selects (e.g., Radix Select); it is specific to Mantine.

[tejas-1206]

@AndrejNemec That's interesting. I just made an observation as I re-installed firefox on my personal mobile (Android) and checked this. Quite weirdly, I can see a static text cursor right next to the selected value in the Select component on the doc. It's like firefox is treating the Select component as a Text Input box (and hence places a text cursor, but no keyboard pops up) instead of treating it as a read-only Input component.

You also pointed out that Radix Select does not have this issue on iOS devices, irrespective of the browser used. So, it can also be an issue from Mantine as well.

My observation and your point about Radix's Select not having this issue while Mantine's Select has, seems to be pointing out that the core input component is probably not configured right in Mantine. What do you think ?

Edit : Well, it can also be firefox issue 😂. Can you check if Radix's Select also behaves the same on firefox ? If no, then we can safely assume the issue lies at Mantine's Select.

[minosss]

Because mantine uses input and radix uses button.

[AndrejNemec]

It happens across all browsers on iOS, not just Firefox. This behavior is present in Safari and Chrome as well.

With Radix Select, this issue doesn’t occur because, as @minosss mentioned, Radix uses a <button> for opening the dropdown, and most other custom select libraries also rely on a <button> or an <input> with filtering functionality.

In Mantine Select, if filtering via the searchable prop is enabled, this issue does not arise.