The only difference between touch-action:manipulation and touch-action:auto is that 'auto' allows double-tap-to-zoom while manipulation doesn't.
But on a page with a mobile viewport, the browser disables double tap to zoom already.
Sites like linkedin.com use a touch-action:manipulation style on all clickable elements, while also having a mobile viewport. I speculate that this was done as a workaround for this pre-iOS 11 Safari bug: https://bugs.webkit.org/show_bug.cgi?id=156232. This is bad for scroll performance today (since touch-action causes scroll start to block on main), but probably more importantly long term it's just a waste of effort for us to be computing touch-rects for all these touch-action: manipulation regions (blink now, and also cc side in the future with xidachen's work). You can see this in the attached screenshot where the devtools "scrolling performance issues" option is enabled.
Here's one way we could solve this in a general way:
- Generalize the notion of the "inherited_action" in StyleAdjuster's
AdjustEffectiveTouchAction to allow the embedder to pass in the
containers effective touch action.
- Perhaps this is the right way to solve issue 759042 anyway?
- When we decide to disable double-tap zoom based on the viewport
tag, set the "inherited action" for the top document to
'manipulation'
- This is dynamic so will need some way to update when the
viewport changes
- Only add touch rects and send SetTouchAction messages for regions
where the effective touch action is different from the
"inherited action" (instead of whenever it's non-auto).
|
Deleted:
Screenshot from 2017-08-25 12:26:47.png
115 KB
|
|
Screenshot from 2017-08-25 12:26:47.png
115 KB
View
Download
|
|
Comment 1 by dtapu...@chromium.org
, Aug 29 2017Owner: xidac...@chromium.org
Status: Assigned (was: Untriaged)