The email textfield in sign in webpage doesn't gain focus on iOS devices

[crazytonyli]

Quick summary

The OAuth2 authorization link (*) redirects to the login web page. On iPhone or iPad, the email textfield on login web page doesn't automatically gain focus when finish loading.

• You'll need to create an app on WordPress.com to create the oauth2 link. Here is an example link: https://public-api.wordpress.com/oauth2/authorize?client_id=&redirect_uri=&response_type=code&scope=global

Steps to reproduce

1. Create an app on WordPress.com: https://developer.wordpress.com/apps/ to prepare a OAuth2 authorization link (see the summary above).
2. Open the link on an iPhone or iPad.
3. Check out the email text field.

What you expected to happen

The email text field gains focus, and the iOS keyboard shows up.

What actually happened

The email text field is highlighted as if it's in focus. However, the iOS keyboard doesn't show up.

Impact

All

Available workarounds?

No but the platform is still usable

If the above answer is "Yes...", outline the workaround.

No response

Platform (Simple and/or Atomic)

No response

Logs or notes

Slack conversation: p1729073374950389-slack-C029GN3KD

---

Here is a recording on iPad.

iPad.mp4

This issue on iOS simulators is more dramatic.

Simulator.mp4

[Robertght]

I was not able to replicate the issue because it seems that we're missing some steps in the process.

@obenland I can see that you've confirmed in Slack the presence of the issue therefore I'm marking this as Triaged and letting this to be assigned later for the right team.

📌 Message to Author
@crazytonyli, if possible, please share the steps you've taken in detail so anyone else can replicate the issue as well. Thank you!

[obenland]

To reproduce on a mobile device:

1. Open an incognito browser window.
2. Navigate to https://public-api.wordpress.com/oauth2/authorize?client_id=11&redirect_uri=x-wordpress-app://oauth2-callback&response_type=code&scope=global
3. Note how the input looks like it's in focus, but the cursor is not active and the keyboard doesn't open automatically.

[andregardi]

I was able to reproduce that also with Android device, Galaxy Flip 5, using steps @obenland mentioned above.
I am also coming to the conclusion that mobile browsers are intentionally preventing keyboard to open programmatically without explicit user interaction.

I tried to find a workaround on Google and Stackoverflow. Most discussions on this seems to be 10 years old. At the time it was suggested to force focus(), click() and touchstart () events to simulate interaction. But that does not work today.

MDN Web Docs - Mozilla points navigator.virtualKeyboard.show() as possible workaround. But this is an experimental feature and is not available for iOS. I also could not make it work even on my android phone.

I also asked on chat gpt which confirmed user interaction is required.

iOS requires some form of explicit user interaction (like a tap or click) before the virtual keyboard is opened. You might ensure that the focus or click event happens as a direct result of a user action. Try attaching the focus() call within a real user event, like a touchstart, rather than when the site is ready without user interaction.

A more recent discussion on stackoverflow also points on that direction:

Programmatic focus using element.focus() doesn't trigger the system-level keyboard to open because WKWebView only shows the keyboard if the focus is initiated by a user. When the focus is triggered during user script evaluation, it is not considered as user interaction.

[andregardi]

Besides the technical issue I mentioned above, I want to double check:
Do we really want to display the keyboard immediately for smartphone? At least on my phone it blocks the third party auth, like Google and Apple logins.

(not my actual phone)

[obenland]

@crazytonyli @jkmassel It sounds like this is expected behavior? The keyboard covering up social logins is a good point that I hadn't considered.

[crazytonyli]

@andregardi Thanks for looking into this.

Programmatic focus using element.focus() doesn't trigger the system-level keyboard to open because WKWebView only shows the keyboard if the focus is initiated by a user.

I wasn't aware of this. I don't think we need to force showing the virtual keyboard then. Feel free to close this issue if you all agree.

[obenland]

Thank you!