Opened 7 years ago

Closed 6 years ago

Last modified 5 years ago

#17036 closed defect (fixed)

dojox/mobile/ScrollableView: Cursor doesn't scroll along with textbox when scroll page.

Reported by: Sebastien Brunot Owned by: Adrian Vasiliu
Priority: undecided Milestone: 1.9.1
Component: DojoX Mobile Version: 1.8.1
Keywords: Cc: Adrian Vasiliu
Blocked By: Blocking:

Description

Description: [mobile scrollableView with input]: The cursor doesn't float along with textbox when scroll page up/down, it just sticks at initial position of the screen.

test configuration: dojo 1.8.1 /iPad2 /iOS 5.1.1 /Safari and Chrome Test page: all ScrollableView test page which contains input element. Step:

  1. Open dojo_1.8.1/dojox/mobile/tests/test_ScrollableView-v-inp.html with Safari or Chrome on iPad.
  2. Tab in one textbox, then virtual keyboard pop up and cursor shows up and blinks in textbox.
  3. Try to scroll page up or down.
  4. Observe position of the cursor.

Attachments (1)

ticket17036.patch (6.3 KB) - added by Sebastien Brunot 7 years ago.
On iOS, make sure the input caret stays in the active input field when scrolling (IBM CCLA).

Download all attachments as: .zip

Change History (18)

Changed 7 years ago by Sebastien Brunot

Attachment: ticket17036.patch added

On iOS, make sure the input caret stays in the active input field when scrolling (IBM CCLA).

comment:1 Changed 7 years ago by Sebastien Brunot

I've attached a ticket that partially fix the issue: when scrolling with the finger on the touch screen, the input caret is moved to the active input or textarea field by updating and then reverting the value of the field. The remaining problem is that the input caret stays at the initial position of the input field during the final transition that occurs when the user lift its finger (but the caret is then set back to the input field when the transition is achieved).

Patch tested on iOS 5 (ipad 1) and iOS 6 (iphone 4).

comment:2 Changed 7 years ago by Eric Durocher

Cc: Adrian Vasiliu added

comment:3 Changed 7 years ago by Adrian Vasiliu

Related: #16363 (fixed in trunk/1.9). This addresses issues of the scrolling itself (unwanted "bouncing back"), while not solving totally the issue with the cursor. However, I've recently tested, with trunk/1.9 on iPhone iOS 6, a ScrollableView containing TextBox widgets in both a webapp and a hybrid Cordova 2.5 app: interestingly, the cursor issues were completely absent in the Cordova app.

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

comment:4 Changed 7 years ago by Eric Durocher

Milestone: tbd1.9.1

comment:5 Changed 7 years ago by Patrick Ruzand

Owner: changed from Eric Durocher to Patrick Ruzand
Status: newassigned

comment:6 Changed 6 years ago by Adrian Vasiliu

Owner: changed from Patrick Ruzand to Adrian Vasiliu

comment:7 Changed 6 years ago by Adrian Vasiliu

Summary: [mobile scrollableView]: Cursor doesn't scroll along with textbox when scroll page.dojox/mobile/mobileScrollableView: Cursor doesn't scroll along with textbox when scroll page.

sbrunot, your patch includes a new test file (test_ScrollableView-inputs.html) while the issue seems also reproducible using the existing test_ScrollableView-v-inp.html (where "inp" stands for "inputs"). Just wondering if it's really worth adding yet another test file. Is there a particular reason?

comment:8 Changed 6 years ago by Adrian Vasiliu

Summary: dojox/mobile/mobileScrollableView: Cursor doesn't scroll along with textbox when scroll page.dojox/mobile/ScrollableView: Cursor doesn't scroll along with textbox when scroll page.

comment:9 Changed 6 years ago by Adrian Vasiliu

Another point to be checked: I reproduce the same issue on Android (at least HTC One X Android 4.1.1 stock browser), so is there a particular reason to restrict this patch to iOS?

And would be nice to use win.doc.activeElement instead of document.activeElement (win = dojo/_base/window).

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

comment:10 Changed 6 years ago by Sebastien Brunot

No reason to add another test file, I supposed I added it because I missed the existing one. For the reason why the patch concerns iOS, it is that I didn't reproduce the issue myself on another platform than iOS. On Android, I remember that the issue was different: the caret would stay in the overlay input field added by the stock browser, and this field will not move, which is a different issue.

comment:11 Changed 6 years ago by Adrian Vasiliu

With the test case mentioned in the description (test_ScrollableView-v-inp.html), on HTC One X Android 4.1.1 stock browser it goes this way:

a) Current trunk (before patch)

Touching a text field makes appear a caret (vertical bar), which follows the field during the scrolling animation but disappears after scrolling.

b) After applying a modified variant of your patch (removing the restriction to iOS)

Now the caret not only follows the field during the scroll but it also no longer disappears at the end of the scroll.

So at least on this Android case the patch seems to bring a benefit. Now, for sure it can go differently on different browsers and Android versions. If you are not confident in applying it on all browsers, or don't have time to test, then it is better to stick with the iOS only version. On the contrary, if logically the code introduced by the patch holds for all browsers and testing goes well, the restriction to iOS can be removed. Your take.

comment:12 Changed 6 years ago by Sebastien Brunot

I'd be more confident for a first commit that solves the issue on iOS only (current patch), and then maybe a second one that solves also the issue on Android (and maybe some other devices ?) after I had time to perform tests on a bunch of devices... How does that sounds ?

comment:13 Changed 6 years ago by Adrian Vasiliu

Okay. So iOS only for the moment.

Now, while I tested it successfully on iOS 5 and 6, in Safari and Chrome, it doesn't seem to bring any improvement on iOS 4 (iPhone 4). But iOS 4 is much lower priority, so there's still enough value in the patch.

The test has("ios") could have been placed inside the function which does the work, but let's say we keep it as it is such that if necessary users can call this undocumented function as fallback (on non-iOS browsers).

I'll skip the test case from the patch, since we already have one.

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

comment:14 Changed 6 years ago by Adrian Vasiliu <vasiliu@…>

Resolution: fixed
Status: assignedclosed

In dcc89ba51a83592e65b3daa84f216c0f5507e57e/dojox:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:15 Changed 6 years ago by Adrian Vasiliu <vasiliu@…>

In 68fdd858887cf9f5a9f82f2d0ca74d76fd10aeb0/dojox:

Error: Processor CommitTicketReference failed
Unsupported version control system "git": Can't find an appropriate component, maybe the corresponding plugin was not enabled? 

comment:16 Changed 6 years ago by Adrian Vasiliu

Committed after triple checking that in no scenario the temporary change of the input field value done in this patch can trigger events, thus possibly disturbing some applications. Tested also using dijit/form/ValidationTextBox. All good.

The commit differs from the patch by the use of win.doc.activeElement instead of document.activeElement, and minor cosmetics in the test file.

Sebastien: At a second look, I decided to include your own test file, because it allows to test with different input types while your lib change is sensitive wrt. to that. Another reason to keep this test is that... it exhibits a distinct trouble of view sizing after orientation change while the keyboard is open on ipad (to be treated separately).

comment:17 Changed 5 years ago by Adrian Vasiliu

The picture with iOS 8.x (tested in 8.1.2) is the following: this workaround is still necessary such that the caret follows the scroll, but it also has a side-effect: if the user moves the caret to, say, the middle of the text, then scrolls, the caret moves to the end of the text as soon as the user touches the ScrollableView?.

If code is added to restore the caret position after altering the input text (as done in this workaround of the iOS issue), it creates other side-effects, such as blinking cursor.

The issue seems relatively minor, though.

Note: See TracTickets for help on using tickets.