Opened 6 years ago

Closed 6 years ago

Last modified 6 years ago

#16363 closed defect (fixed)

dojox/mobile/ScrollableView: when it contains input fields, it wrongly bounces back after navigating from one field to another using TAB/shift-TAB (desktop) or PREV/NEXT (iPhone's soft keyboard)

Reported by: Adrian Vasiliu Owned by: Eric Durocher
Priority: undecided Milestone: 1.9
Component: DojoX Mobile Version: 1.8.1
Keywords: Cc:
Blocked By: Blocking:

Description

When a ScrollableView contains input fields (say, dojox/mobile/TextBox), and the user navigates from a field to another using TAB/shift-TAB (on desktop browsers) or PREV/NEXT (using iPhone's soft keyboard), there are situations when this leads to browser scroll. This scroll is expected (to keep the edited field in the view), but it appears to confuse the scrolling machinery of ScrollableView, which now wrongly bounces back when trying to scroll till the top. Forcing the scroll till the bottom fixes it.

How to reproduce:

  1. Load the attached test_Textbox-in-ScrollableView?.html (place it dojox/mobile/tests) on potentially any desktop or mobile browser.
  2. Scroll till the text boxes in the middle of the scrollable view are visible.
  3. Click/touch a text box (on mobile devices, the soft keyboard is now visible).
  4. Press TAB (desktop) or touch NEXT (iPhone) to navigate from a text box to the next one.
  5. Navigate from field to field till the next text box is out of the visible area. Now, navigating again to the next text box produces browser scroll.
  6. On iPhone, close the soft keyboard (touch DONE).
  7. Try to scroll the list till the top.

==> It bounces back before the top.

Reproduced on latest Chrome and FF (so not only webkit), and on iPhone iOS 6.0.1 and iPad iOS 5.1.

Reproduced with both latest Dojo (latest trunk and latest 1.8.1 branch), and with Dojo 1.7.3 as well.

Attachments (4)

test_TextBox-in-ScrollableView.html (19.9 KB) - added by Adrian Vasiliu 6 years ago.
Test case for reproducing the bug.
test16363.patch (11.0 KB) - added by Adrian Vasiliu 6 years ago.
Test case for TextBox inside ScrollableView (with fixed header and footer) - Adrian Vasiliu, IBM, CCLA
patch16363.patch (1.3 KB) - added by Adrian Vasiliu 6 years ago.
Avoid misbehavior of scroll after navigating among input fields - Adrian Vasiliu (IBM, CCLA)
patch16363-fixIE8.patch (1.7 KB) - added by Adrian Vasiliu 6 years ago.
Avoid regression in IE8 (at the price of not fixing the original issue in IE8) - Adrian Vasiliu (IBM, CCLA)

Download all attachments as: .zip

Change History (14)

Changed 6 years ago by Adrian Vasiliu

Test case for reproducing the bug.

comment:1 Changed 6 years ago by Adrian Vasiliu

When using TAB/shift-TAB in desktop browsers or PREV/NEXT (or other equivalents) on the soft keyboard of mobile browsers, a browser scroll occurs. Now, in all tested browsers (Mobile Safari, Windows Safari, various Android, Chrome, FF), this translates (how?...) into a value of scrollableView's domNode.scrollTop which changes from zero to greater than zero. Then, the scrolling machinery of ScrollableView gets messed up. (Additionally, on iOS there is also a window.pageYOffset, but this one appears harmless for us. There is also a scrollTop at the level of the body, as soon as the soft keyboard shows up, and this value changes when navigating the fields.)

About the attached patch16363.patch:

  • It only fixes the issue described in this ticket. It has no impact (positive or negative) on other issues related with editing of input fields inside scrollable views (in terms of (re)sizing, ability to scroll all over the content, (mis)behavior of fixed headers/footers, ugliness on various Android devices etc.).
  • It may not be the best possible solution. I put it here to have a something in hands, while it may be replaced later by a better one.
  • I have tried several other approaches, mainly to modify the scrolling machinery such that it can still work when domNode.scrollType > 0. This worked, but with bad side-effects on the scrollbars that I couldn't avoid.
  • Tested ok on latest Chrome and FF, iPhone and iPad devices and simulators (iOS 5 and 6), and a few Android devices. If there will be no better solution and we'll want to go with this one, I will perform further testing.
Last edited 6 years ago by Adrian Vasiliu (previous) (diff)

Changed 6 years ago by Adrian Vasiliu

Attachment: test16363.patch added

Test case for TextBox inside ScrollableView (with fixed header and footer) - Adrian Vasiliu, IBM, CCLA

comment:2 Changed 6 years ago by cjolif

In [30080]:

refs #16363. Update the test case

comment:3 Changed 6 years ago by leopatras

Is there any chance that this patch is going into the next release? Otherwise ScrollableView? is not usable with Edit fields on it on IOS.

comment:4 Changed 6 years ago by Adrian Vasiliu

For sure there will be a solution for this problem in the next release (Dojo 1.9). The solution might be this patch, or a better one. It might also go into a future 1.8.x.

comment:5 Changed 6 years ago by cjolif

Milestone: tbd1.9

Changed 6 years ago by Adrian Vasiliu

Attachment: patch16363.patch added

Avoid misbehavior of scroll after navigating among input fields - Adrian Vasiliu (IBM, CCLA)

comment:6 Changed 6 years ago by Adrian Vasiliu

(uploaded a slightly refreshed variant of the initial patch - no behavior change)

comment:7 Changed 6 years ago by cjolif

Resolution: fixed
Status: newclosed

In [30781]:

fixes #16363. Avoid misbehavior of scroll after navigating among input fields. Thanks Adrian Vasiliu (IBM, CCLA). !strict.

Changed 6 years ago by Adrian Vasiliu

Attachment: patch16363-fixIE8.patch added

Avoid regression in IE8 (at the price of not fixing the original issue in IE8) - Adrian Vasiliu (IBM, CCLA)

comment:8 Changed 6 years ago by Adrian Vasiliu

Please reopen - due to regression in IE8 found by Akira Sudoh. Indeed, addEventListener does not exist in IE8. The attached patch16363-fixIE8.patch fixes the regression, at the price of not fixing the original issue in IE8.

comment:9 Changed 6 years ago by Ed Chatelain

In [30882]:

Fixes #16363. Fix problem with previous fix on IE8, addEventListener does not exist in IE8. This fixes the regression, at the price of not fixing the original issue in IE8.. Thanks Adrian Vasiliu (IBM, CCLA). !strict

comment:10 Changed 6 years ago by Eric Durocher

In [31334]:

fixes #16948, refs #16363. Fix regression caused by "scroll" listener added to fix #16363, and which was not removed on view destroys. Thanks Adrian Vasiliu (IBM, CCLA). !strict

Note: See TracTickets for help on using tickets.