Opened 5 years ago

Closed 4 years ago

#18360 closed defect (wontfix)

Scrolling corrupted in mobile ScrollableView on iOS 8 Safari when keyboard is up

Reported by: red3 Owned by: Adrian Vasiliu
Priority: undecided Milestone: tbd
Component: DojoX Mobile Version: 1.9.5
Keywords: Cc:
Blocked By: Blocking:

Description

Inside a ScrollableView?, when selecting an textbox or textarea, the keyboard comes up, the textbox may not come into view (being overlaid by the the keyboard). When scrolling the view the cursor, as well as the text selection highlight box, seems detached from the textbox, and the scrolling is out of sync with my finger action, being very jittery and often scrolling in the opposite direction to my finger's movement. When changing the device orientation, the input field may move out of view and typing on the keyboard will not bring it back into view.

After hiding the keyboard the scrolling behaviour returns to normal. Replacing dojox/mobile/ScrollableView with dojox/mobile/View resolves the issue. But this means you have to sacrifice fixed headers and footers.

Tested on iPhone 5 and iPhone 6 Plus with iOS 8.1 Also tested in Chrome for iOS 8 on the same devices and the problem does not manifest. Problem does not manifest on iOS7 Safari.

Attachments (6)

IMG_0056.PNG (248.6 KB) - added by red3 5 years ago.
Cursor detached from TextArea?
IMG_0052.PNG (166.9 KB) - added by red3 5 years ago.
Gray text highlight box detached from Expanding TextArea?
IMG_0059.PNG (219.1 KB) - added by red3 5 years ago.
Blue vertical cursor detached from TextArea? as view is scrolled
test_HTML-inputs-overflow-scroll-no-dojo.html (2.6 KB) - added by Adrian Vasiliu 5 years ago.
Test case with pure HTML (no Dojo) and using overflow:scroll ("native") scrolling
test_HTML-inputs-CSS-scroll-no-dojo.html (4.2 KB) - added by Adrian Vasiliu 5 years ago.
Test case with pure HTML (no Dojo) and using CSS transform scrolling
test_HTML-inputs-overflow-scroll-no-dojo-v2.html (4.6 KB) - added by Adrian Vasiliu 5 years ago.
Test case with pure HTML (no Dojo) and using CSS transform scrolling (a more realistic version)

Download all attachments as: .zip

Change History (15)

Changed 5 years ago by red3

Attachment: IMG_0056.PNG added

Cursor detached from TextArea?

Changed 5 years ago by red3

Attachment: IMG_0052.PNG added

Gray text highlight box detached from Expanding TextArea?

Changed 5 years ago by red3

Attachment: IMG_0059.PNG added

Blue vertical cursor detached from TextArea? as view is scrolled

comment:2 Changed 5 years ago by Adrian Vasiliu

Owner: set to Adrian Vasiliu
Status: newassigned

Changed 5 years ago by Adrian Vasiliu

Test case with pure HTML (no Dojo) and using overflow:scroll ("native") scrolling

Changed 5 years ago by Adrian Vasiliu

Test case with pure HTML (no Dojo) and using CSS transform scrolling

comment:3 Changed 5 years ago by Adrian Vasiliu

when selecting an textbox or textarea, the keyboard comes up, the textbox may not come into view (being overlaid by the the keyboard) [...] When changing the device orientation, the input field may move out of view and typing on the keyboard will not bring it back into view.

These parts are already covered by #18281.

When scrolling the view the cursor, as well as the text selection highlight box, seems detached from the textbox, and the scrolling is out of sync with my finger action, being very jittery and often scrolling in the opposite direction to my finger's movement.

These are Safari / iOS 7 and 8 bugs. There are a number of references about it on the web, see mainly https://bugs.webkit.org/show_bug.cgi?id=138201. I attached test files in pure HTML (without Dojo) reproducing the issues:

Both reproduce these issues on iOS 8 (tested on various iPhones), but also on iOS 7.1.2 (iPhone 5).

Now, dojox/mobile/scrollable does have a workaround code for the cursor issue: https://github.com/dojo/dojox/blob/1.10/mobile/scrollable.js#L621. However, this does not seem effective anymore with the latest 7.x and 8.x. https://bugs.dojotoolkit.org/attachment/ticket/18360/test_HTML-inputs-CSS-scroll-no-dojo.html includes this workaround code (and another variant of it) - it can be activated by changing the withWorkaround variable in the test file.

the scrolling is out of sync with my finger action, being very jittery and often scrolling in the opposite direction to my finger's movement.

This seems to be a side-effect of the workaround code mentioned above. red3, would it be possible for you to test in your context with dojox/mobile/scrollable._keepInputCaretInActiveElement() made no-op (say, by monkey patching or temporarily editing the file) to check if this change improves the situation for this precise issue?

Gray text highlight box detached from Expanding TextArea?

For some reason I wasn't able to reproduce this gray highlight, but to avoid this issue I suggest to remove any setting of the property selectOnClick to true (default is false) from your text widgets.

comment:4 Changed 5 years ago by red3

Thanks for the detailed response Adrian.

I tested the "no Dojo" files and I agree that there are issues with iOS 7/8 keeping the caret in the text field. I observed that if the active text field is scrolled so it is above the viewport it will be brought back into view as text is entered. If it is below the viewport (or behind the keyboard) it will not be brought into view as text is entered. Setting the withWorkaround variable to true was effective.

However, in none of these cases was the jittery scrolling encountered that we experience with ScrollableView?.

When ScrollableView? is enabled in our app, we experience issues in iOS 8 that DO NOT MANIFEST in iOS 7. The form jumps all over the place (in the vertical plane) when scrolled. When the keyboard is put away, these scrolling issues are gone.

I commented out the body of the function _keepInputCaretInActiveElement in scrollable.js and see no improvement. (I am debugging using Safari Dev Tools on a Mac and can see in the source that my changes were applied.)

The corrupted scrolling is an iOS 8 only issue. I do not think that it is a side-effect of the caret positioning workaround. I think it is an incompatibility of the DoJo? scrolling technique with iOS 8.

comment:5 Changed 5 years ago by Adrian Vasiliu

I commented out the body of the function _keepInputCaretInActiveElement in scrollable.js and see no improvement.

Just to be sure I focus my investigation in the right direction, you did these tests with which Dojo version? The one mentioned in the ticket (1.9.5)? Or 1.10.x?

In any case, I will further dig into it, but be aware I'll not be able to work on it before next Tuesday.

For now, I'd add a suggestion which can fix one of the issues with a highlight area that doesn't scroll together with the text element. While typing, by default Safari (as other browsers) suggests corrections and highlights the typed text, which can "detach" when scrolling. You can avoid this issue by disabling browser's "autocorrect" feature (if you do not absolutely need it):

<input data-dojo-type="dojox/mobile/TextBox"
  autocorrect="off"
  ...
>

(You may also want to additionally set autocomplete="off" and autocapitalize="none".)

Last edited 5 years ago by Adrian Vasiliu (previous) (diff)

comment:6 Changed 5 years ago by red3

We're using 1.9.5 but also tried 1.10.x (both have the iOS8 'strict' patch). There were some differences in encoding output in 1.10 that we didn't have time to address, so we stayed with 1.9. (We're releasing this month. No desire to do a full regression just because of a DoJo? release!) We have not detected any difference in scrolling behaviour between the two versions.

Changed 5 years ago by Adrian Vasiliu

Test case with pure HTML (no Dojo) and using CSS transform scrolling (a more realistic version)

comment:7 Changed 5 years ago by Adrian Vasiliu

To recap, there are a number of different misbehaviors hurting input elements, covered by this ticket and by #18281. For some, I've suggested workarounds. They all look as Safari iOS 8 bugs (some also hurt Safari iOS 7.1.x).

Now, to focus on the main issue raised in the present ticket, that is "the scrolling is out of sync with my finger action, being very jittery and often scrolling in the opposite direction to my finger's movement", the attached https://bugs.dojotoolkit.org/attachment/ticket/18360/test_HTML-inputs-overflow-scroll-no-dojo-v2.html implements, in pure HTML/CSS (without Dojo), a more realistic (but still very rough) version of the scrolling mechanism used by dojox/mobile/scrollable. At least on iPhone 6 iOS 8.1 it allows to reproduce the issue (this one being specific to iOS 8.x). Apparently, Safari iOS 8.x keeps trying to get the focused input element in the middle of the visible area, thus "competing" with user's scroll gesture. I have experimented with a number of candidate workarounds, nothing did the trick. I perfectly understand the frustration, but I'm out of ideas and of available time, for now. A future Safari update might fix some or all of the broken things, or maybe we'll find a workaround, but I can't promise anything.

The blinking caret issue (https://bugs.webkit.org/show_bug.cgi?id=138201) also hurts bootstrap: https://github.com/twbs/bootstrap/issues/14708

Other issues related with input elements in iOS 8 (I pick one among many): http://stackoverflow.com/questions/25928605/in-ios8-safari-readonly-inputs-are-handled-incorrectly/26928381#26928381.

comment:8 Changed 5 years ago by Adrian Vasiliu

Also, FYI, most of the issues go away by embedding the webapp in a Cordova container. Tested with Cordova 3.5 on both iOS 8.1.1 and iOS 8.2 beta. The issues which go away include:

  • "the scrolling is out of sync with my finger action, being very jittery and often scrolling in the opposite direction to my finger's movement"
  • "when selecting an textbox or textarea, the keyboard comes up, the textbox may not come into view (being overlaid by the the keyboard) [...] When changing the device orientation, the input field may move out of view and typing on the keyboard will not bring it back into view."

comment:9 Changed 4 years ago by Adrian Vasiliu

Resolution: wontfix
Status: assignedclosed

Closing the ticket since the remaining issues are iOS bugs for which there is no known workaround.

Note: See TracTickets for help on using tickets.