Page MenuHomePhabricator

Input field in link label dialog is not focused on iOS
Open, LowestPublic

Description

Expected behavior

  1. Tap an existing link
  2. Tap the link label edit pencil in the edit card
  3. Link label dialog opens
  4. Cursor is placed in label text input field, soft keyboard is visible

Actual behavior

  1. Tap an existing link
  2. Tap the link label edit pencil in the edit card
  3. Link label dialog opens
  4. ⚠️Label text input field is out of focus, soft keyboard is not visible

Configuration

iOS: Safari + Chrome

Event Timeline

ppelberg renamed this task from Input field in link dialog is not focused on iOS to Input field in link label dialog is not focused on iOS .Aug 7 2019, 5:31 PM
ppelberg updated the task description. (Show Details)

This also happens for link targets

So it turns out that iOS will not properly focus an input unless it happens during the same event cycle as a user event (e.g. click): https://stackoverflow.com/questions/12204571/mobile-safari-javascript-focus-method-on-inputfield-only-works-with-click

Because we open dialogs with a transition, the input fields are not ready for focusing until some time after the click (~250ms), so with the way dialogs are currently implemented in OOUI this is not possible to fix.

Below are notes for anyone in the future attempting to resolve this.


In theory this would be possible if the focus call happened during the click event cycle. Currently focus calls are in getReadyProcess. They used to be in getSetupProcess, which is the earliest they can run (i.e. after the DOM has been built), but some browsers didn't like us focusing elements that were scaled or had 0% opacity. This probably isn't the case for iOS Safari, so we could refactor this into "focusDialog" and call that as soon as the current browser allows (i.e. special case browsers that require us to wait for getReadyProcess).

Moving the call to getSetupProcess still doesn't resolve the issue though, as there are about 6 setTimeouts between the click and setup due to WindowManager and various promise chains (jQuery promises are always async, like native ones). It may be possible to ensure that the DOM is built immediately and then focused, by stripping away the promises, but this will require a huge rewrite of WindowManager.


tl;dr Fixing this is effectively impossible

Volker_E triaged this task as Lowest priority.Sep 16 2019, 7:43 PM
Aklapper added a subscriber: Esanders.

Removing task assignee due to inactivity, as this open task has been assigned for more than two years. See the email sent to the task assignee on February 06th 2022 (and T295729).

Please assign this task to yourself again if you still realistically [plan to] work on this task - it would be welcome.

If this task has been resolved in the meantime, or should not be worked on ("declined"), please update its task status via "Add Action… 🡒 Change Status".

Also see https://www.mediawiki.org/wiki/Bug_management/Assignee_cleanup for tips how to best manage your individual work in Phabricator.