Dialog: native overflow scrolling on ios5+

[lee]

We've had several requests to improve scrolling features on dijit/Dialog content that overflows.
No scrollbars are ever shown on overflowed content, it's un-intuitive to a user and not obvious there is overflowed content.
Only IOS5+ supports -webkit-overflow-scrolling so this is a minor feature request.
Another option is mixing in "dojox/mobile/_ScrollableMixin" to a Dialog for other mobile versions, which I have working but doesn't feel right

Should this be something we do outside the toolkit or part of it considering mobile support changes so often?

[lee]

ios overflow -webkit-overflow-scrolling patch

[bill]

I'm confused, can you explain more?

My feeling is that on mobile, it's never a good idea to have internal scrollbars (ie, scrollbars on a <div> rather than on the viewport itself), but that's a big change for dijit.Dialog. Is that the problem you are talking about, or something more specific?

And why are you talking about iOS5 in particular? Isn't the usability issue across Dialog on all mobile devices and OS versions? I guess your patch only fixes Dialog on iOS5?

[lee]

Sorry, yes the issue is scroll bars on block elements with overflow:scroll and yes it effects every mobile device.
The problem we have is that while a dijit/Dialog looks fine on a desktop (and may display scrollbars), when it gets down to the size of mobile screens Dialog content will nearly always overflow, won't show scroll bars and doesn't make it obvious to the user there is overflowed content

About ios5, yes -webkit-overflow-scrolling is only supported on IOS5 and up, it effectively does the job of mobile/ScrollableView however #16012 doesn't make good reading.

Any advice would be appreciated for other options to pursue

[bill]

I'll think about it. Another question: what does adding webkit-overflow-scrolling achieve on IOS5 beyond the current behavior of Dialog? Single finger scrolling? Visible scrollbars even when not touching the screen?

BTW you should be able to set -webkit-overflow-scrolling in dijit.css; you don't need to modify the javascript source code.

[lee]

Thanks bill
Safari explain it here ​http://developer.apple.com/library/safari/#documentation/appleapplications/reference/safaricssref/articles/standardcssproperties.html
It looks native and doesn't show scrolls till dragged and uses inertial scrolling.

Regarding CSS, that's what I initially tried and it wasn't working on the device, I'm presuming it's caching and will try again tonight, however I thought it may have been due to _size() setting overflow: "auto" whenever a resize is called.

-webkit-overflow-scrolling does appear to be buggy though, I've seen a couple of blogs say to get better rendering safari needs to be forced to use hardware acceleration - through a noop webkit-transform: translate3d(0,0,0)

Alternatively I could look at virtual scrolling, something like ​http://jsfiddle.net/lbod/eAYsM/8/

[lee]

Apologies, CSS alone is fine .dijitDialogPaneContent {-webkit-overflow-scrolling:touch; overflow:auto;}
There's some very weird behaviour when pinch/zooming to the point it stops any scrolling however setting a viewport meta tag sorts it out

<meta name="viewport" content="initial-scale=1, maximum-scale=1">

[bill]

OK, I'll add that in; it will at least make things better for iOS6+ users. I don't think the overflow:auto is necessary though since Dialog already sets that programatically in the _size() method.

[bill]

In [29891]:

Use -webkit-overflow-scrolling so that Dialog scrolls better on iOS5+, fixes #16170.

[bill]

In [31063]:

use -webkit-overflow-scrolling for all ContentPanes, not just Dialog, refs #16170.

[Colin Snover]

bill, would you be comfortable with this fix being backported through to 1.7? It does not seem to negatively impact anything but I wanted to be sure before I went ahead and did it.

[bill]

Sure, seems fine, thanks.

[Nick Nisi]

Was this ever backported to 1.8 and 1.7? I'm not seeing -webkit-overflow-scrolling anywhere on the 1.8 or 1.7 branches. Were there any issues discovered with backporting this?

[bill]

Presumably the earliest version it's fixed in is 1.9. That's why the milestone on the ticket says "1.9".

[Nick Nisi]

Right, ok. I wasn't sure because in comment:9 it was asked if it was ok to backport it through 1.7.

[bill]

Oh good point, I didn't notice those two comments. OK, so I guess csnover planned to backport it but forgot?