Opened 9 years ago

Closed 8 years ago

Last modified 8 years ago

#16012 closed task (fixed)

dojox/mobile/ScrollableView: explore/evaluate the use of "native" scroll

Reported by: Adrian Vasiliu Owned by: Adrian Vasiliu
Priority: undecided Milestone: 2.0
Component: DojoX Mobile Version: 1.8.0
Keywords: Cc: cjolif
Blocked By: Blocking:


The purpose of this ticket is to collect information and to host discussions about an alternative to the current mechanism of dojox/mobile/ScrollableView: relying on browser's native scroll (overflow:scroll).

As known, the ScrollableView disables the browser scrolling and implements the scrolling behavior by its own. The main reason is that one-finger scrolling inside inner DIVs wasn't supported by webkit browsers such as mobile Safari (iOS). This situation changed in iOS5, and scrolling in inner DIV's is also supported by recent Android versions. On the other side, our scrolling machinery works very well on iOS4 and iOS5 (iOS6 might be a different story), but encounters various troubles on some Android devices/versions (this was the reason a number of modes and workarounds have been implemented in the past). All in one, let's evaluate whether nowadays the use of native browser's scrolling capabilities can bring us an improvement (possibly using it selectively, depending on the platform).

Attachments (2)

patch16012-nativeScroll.patch (43.4 KB) - added by Adrian Vasiliu 9 years ago.
Pure experimental stuff: addition a "native" scrollType mode for ScrollableView. Includes a test allowing to compare the different scroll types. - Adrian Vasiliu, IBM, CCLA
patch16012-nativeScroll-v2.patch (12.1 KB) - added by Adrian Vasiliu 9 years ago.
Experiment with "native" scrolling. Updated and adapted for working on top of Dojo 1.9.0. - Adrian Vasiliu, IBM, CCLA

Download all attachments as: .zip

Change History (18)

Changed 9 years ago by Adrian Vasiliu

Pure experimental stuff: addition a "native" scrollType mode for ScrollableView. Includes a test allowing to compare the different scroll types. - Adrian Vasiliu, IBM, CCLA

comment:1 Changed 9 years ago by Adrian Vasiliu

The attached patch16012-nativeScroll.patch aims to allow testing this approach. If proved to be useful, the final packaging of this stuff is to be determined.

The patch includes some minimal changes in the library to add a new scrollType:3 for the "native" scroll, and a test file which allows to compare the behavior of the 4 scroll types (the 3 existing ones, and the new "native" one).

For now, the results go as follows:

  • iPhone 4S iOS 5.0.1: Using overflow:scroll alone does allow scrolling, but it is horribly slow. It becomes fast by adding an Apple-specific setting: webkit-overflow-scrolling:touch. Nice, but this appears to be buggy in iOS5, the areas revealed by scrolling are not redrawn (issue said here and there to be fixed in iOS6).
  • Android 2.x Apparently overflow:scroll is not supported (tested on Galaxy Tab Android 2.2). It has simply no effect, no scrolling is possible.
  • Android 4.x On HTC One X (Android 4.0.3) and Samsung Galaxy Nexus (Android 4.0.4), the native scrolling is very fast... much faster than our old scrolling mechanism. On the negative side:

a) The native scroll is... too fast, that is significantly faster than the scrolling in native apps.

b) The scrollbars do not appear temporarily during the scroll (while they do appear in non-native scroll on Android, and they appear in native scroll on iPhone).

c) There is no touchmove event during the scroll (while on iPhone the events do arrive). (The test file includes debug code for checking the events at document and body levels.)

All in one, at this stage, the native scroll does not seem usable, unless we will find ways to improve it and/or iOS and Android will improve it...

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

comment:2 Changed 9 years ago by Colin Snover

“native” scrolls on iOS using -webkit-overflow-scrolling do not fire scroll events as the element scrolls and so are worthless for anything that requires virtual scrolling.

comment:3 Changed 9 years ago by cjolif

Cc: cjolif added

comment:4 Changed 9 years ago by Adrian Vasiliu

I have mentioned that, on iPhone 4S iOS 5.0.1, the option webkit-overflow-scrolling:touch is needed (in addition to overflow:scroll) to get fast scrolling, but this option produces a corrupted redraw while scrolling, and this was said to be fixed in iOS6.

I just tested on iPhone 4S under iOS 6 and I confirm, this issue is gone.

Now, another trouble on iOS is that, with "native" scrolling, we get browser scrolling when trying to scroll while we are already at top / bottom. This produces the nice bouncing back effect, but at the level of the entire page. Differently, on Android 4.0.3 (HTC One X), trying to scroll over the limit does not produce page scroll, but doesn't produce the bouncing back effect inside the scrollable view either...

Concerning the scroll events, on the iPhone 4S under iOS 6 just as on another iPhone 4S under iOS5 I do get scroll events on scrollableView's domNode (about 5-6 events per scroll gesture). Tested by adding this._ch.push(connect.connect(this.domNode, "onscroll" , this, function(ev) { console.log("onscroll")})); somewhere after line 140 in scrollable.js. As far as I know, these events are not supposed to bubble, so it's normal that we don't get them at the top-level (window, document, body).

(BTW, since iOS6 the console no longer exists in Mobile Safari, instead you can enable the nice remote debugging via the Web inspector in Safari 6+. Funny: the "clear console" command exists, but, at least in my Safari 6.0.1/MacBookPro, it is no-op ;-) Particularly inconvenient when logging events...)

comment:5 Changed 9 years ago by Adrian Vasiliu

See also #16038 (scrolling smoothness regression on iOS6).

comment:6 Changed 9 years ago by leopatras

If there is the chance to get a ScrollableView? with less side effects than the current soft scrolling machinery : +1

comment:7 Changed 9 years ago by Adrian Vasiliu

A number of Trac tickets concerning issues with our current scrolling machinery (in particular in new iOS / Android versions) have been fixed in the last months. I would say it does improve and there are indeed big chances it further improves.

Concerning the replacement with "native" scroll, as said in the previous comments, at this stage such a replacement doesn't seem to be fully satisfactory, but we may of course revisit it. For sure, any contribution or patch submission from the community is warmly welcome.

comment:8 Changed 9 years ago by Paul Christopher

However the current scrolling machinery seems to get confused if you e.g. navigate a list with the tab key, see #17062

comment:9 Changed 9 years ago by nickmaynard

Adrian, would there be a chance of getting an updated version of this patch for the 1.9.0 release? There have been some fairly significant changes to scrollable since the patch was written (mostly yours!) and so this is unlikely to apply cleanly now.

comment:10 Changed 9 years ago by Adrian Vasiliu

Indeed, besides changes that made the patch non-mergeable, there are a few other adaptations needed.

The attached patch16012-nativeScroll-v2.patch applies ok on top of 1.9.0 (rc2). Here are some testing results:

  • iPhone 5 iOS 6.1.3: at a quick testing the native scroll works impressively well, including bouncing back behavior and temporary scrollbars. However, there is a glitch: it enables a horizontal scroll of the entire page (it shouldn't).
  • HTC One X Android 4.0.4: it's not bad, by far faster than the currently available modes, no horizontal page scroll as on iOS, but globally less brilliant: no bouncing back; hard to do small scrolls; no scrollbars; from time to time slow redraw when scrolling fast. Will be tested on newer Android 4.1 and 4.2 too.

Changed 9 years ago by Adrian Vasiliu

Experiment with "native" scrolling. Updated and adapted for working on top of Dojo 1.9.0. - Adrian Vasiliu, IBM, CCLA

comment:11 Changed 9 years ago by Patrick Ruzand

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

comment:12 Changed 8 years ago by Adrian Vasiliu

Owner: changed from Patrick Ruzand to Adrian Vasiliu

comment:13 Changed 8 years ago by Adrian Vasiliu

Milestone: tbd2.0
Resolution: fixed
Status: assignedclosed

Native scroll is now implemented for Dojo 2 (delite/deliteful).

comment:15 Changed 8 years ago by Wouter Hager

Could this be backported to 1.9 / 1.10 please?

comment:16 Changed 8 years ago by Adrian Vasiliu

Backporting isn't the way we decided to go, for the following reasons:

  • As mentioned in the item no. 5 of the FAQ link in my previous comment, the "native" scroll is not compatible with all features of dojox/mobile. Such a change of the scrolling mechanism has deep consequences in terms of events etc.
  • Furthermore, "native" scroll is not supported by all platforms supported by dojox/mobile 1.x.
  • And it could anyway not be a matter of "backporting" from Dojo 2 (delite/deliteful), but rather a re-implementation because the entire design is significantly different.
  • Finally, users that do want native scroll can either
    • Use a simple DIV with native scroll styling, if they don't need features of ScrollableView?, or
    • Use a subclass of ScrollableView? as shown in the FAQ link.
Last edited 8 years ago by Adrian Vasiliu (previous) (diff)
Note: See TracTickets for help on using tickets.