There's a balance here between keeping the user on rails and allowing them to scroll freely.

Keeping them always on rails is a bad user experience, and so is having no rails at all.

The fix here might be as simple as tweaking these constants:
https://cs.chromium.org/chromium/src/ui/events/gesture_detection/snap_scroll_controller.cc?rcl=0&l=16

I could also imagine a fix that scaled the rails a bit based on velocity.

AFAIK we follow Android platform conventions on this.  (If we differ, then the bug should be about that.)

I believe this is something Android thought carefully about in general (since iOS has much stronger railing, Android made a conscious decision to have weaker rails), although if you can prototype a behavior that feels better, it's something we could discuss with them.

I'd also like to know what device you had this impression on.  It can happen this kind of threshold is affected by deviceScaleFactor.

I didn't know Android had a platform convention for rails. I wasn't able to find any information out about it, can you provide a link?

Might not be documented, it's one of those conventions you're supposed to fit just by using the normal gesture handler Java files.

The GestureDetector library doesn't apply rails, does it?

You're right, sorry.  We can do what we want, then.  I tried Google Photos, Maps and the Android PDF reader, and the only one with rails is the PDF reader.  It has significantly weaker rails than Chromium does.

One thought I have is that the point of rails is really to stay locked on a paragraph of text, whereas for every other use case, like photo viewing, the rails tend to be counterproductive.  That's why we've struck this middle ground of somewhat weak railing.  Either strengthening or weakening the rails will harm one of the use cases.

If we want to tweak the rails, I wonder if we could tune it based on what we're currently over.  On desktop pages, we could plumb through paragraphs information from the text autosizer and tie the rails to that.  On mobile pages that are larger than the viewport (which is usually by accident), we could have the simple policy of railing to the left edge of the document.

My intuition is that this approach will make the product feel less predictable. I don't think a user will be able to easily predict where they'll scroll to if it depends what they're over.

I suspect there's a relatively small tweak here that will address rbyers@'s use case while still leaving it fairly easy to break the rails.

Feeding current fling velocity into the scroll snap coordinator would help with this, and I think that would be reasonably rational for users.

Just spent 30 min browsing Facebook.com on a nexus 7 while pinch zoomed in a little (to get the feed to fill the width of my screen).  In that time I'd say I fell off the vertical track I was trying to read along about a dozen times.  Sometimes this was flinging, but sometimes it was just scrolling.  Is it just me being sloppy, or do others experience that too in such a scenario? 

I was thinking we should just bump up the constant - that it was almost certainly better to have stronger rails and not worth the effort to study in detail.  But re-reading the above, maybe that's wrong.

Perhaps there's something simple we could measure that would let us tune a value via Finch?  Eg. I did a bunch of horizontal-only gestures to reposition the viewport, maybe we should aim to minimize that?  I also did a bunch of longer gestures where, after falling off the rails, I repositioned horizontally.  Maybe the thing to measure is how often is a rail-break followed (in that gesture or the next) by deltaX motion approximately opposite to the amount due to the rail-break.  That's got to almost always be bad, right?

When you're falling off the rails, is it consistently during quick gestures? I'm hopeful that it would feel reasonably natural to need to slow down to break the rails.

Maybe we could measure how far off the nearest rail axis we are, split by whether or not we broke the rails?

We'd like to see that when people broke the rails, they scrolled reasonably far off the rails.

Your metric also sounds reasonable, though it's trivially gameable (by never breaking the rails).

I definitely hit some cases where I fell off the rails during a relatively slow gesture.  It's hard to say what the right tradeoff is there though.

BTW the Android weather app is an interesting comparison (vertically scrollable document with some horizontal carousels).  That app has apparently chosen not to permit rail breaking at all.

> Just spent 30 min browsing Facebook.com on a nexus 7 while pinch zoomed in a little (to get the feed to fill the width of my screen). 

In some sense this is an abuse of pinch zooming.  We could also address this by supporting the page-zoom ("plus magnifying glass" icon in URL-bar) on tablets, or tuning default deviceScaleFactor on tablets (it's a common pattern for the OEM-specified one to make text too small and create margins on tablets).