Bug 104730 – [Chromium] Non-fast scrollable region should be scaled

• Status: RESOLVED
• Resolution: DUPLICATE
• Component: Layout and Rendering

[Xianzhu Wang]

Currently all scrollable areas in a page are marked as non-fast scrollable regions of the scroll layer of the containing frame. When calling WebLayer::setNonFastScrollableRegion(), the passed region is in CSS pixels, then Chromium's LayerImpl uses the region to check if a touch point (in logical pixels) is in non-fast scrolling area. This causes incorrect scrolling behavior when the page is scaled. For example, when page scale factor > 1, when trying to scroll an area by starting from the bottom right part of the area, the area is not scrolled but the whole page is scrolled because it falls back to the whole page fast scrolling path.

Though eventually we'll enable fast scrolling for the scrolling areas as many as possible, for now we need to fix the slow scrolling path for them.

Tried the following change and it works:

 void ScrollingCoordinatorChromium::setNonFastScrollableRegion(const Region& region)
 {
     // We won't necessarily get a setScrollLayer() call before this one, so grab the root ourselves.
     setScrollLayer(scrollLayerForFrameView(m_page->mainFrame()->view()));
     if (m_private->scrollLayer()) {
         Vector<IntRect> rects = region.rects();
         WebVector<WebRect> webRects(rects.size());
         for (size_t i = 0; i < rects.size(); ++i) {
+            rects[i].scale(m_page->pageScaleFactor());
             webRects[i] = rects[i];
         }
         m_private->scrollLayer()->setNonFastScrollableRegion(webRects);
     }
 }


Will upload a formal patch containing layout test soon.

[Xianzhu Wang]

Discussed with Tien-Ren. Perhaps we should not scale in WebKit, but should apply required scales and transformations when hit-testing the non-fast scrollable region in cc. If yes, we should close this bug and work in Chromium instead.

[James Robinson]

(In reply to comment #1)
> Discussed with Tien-Ren. Perhaps we should not scale in WebKit, but should apply required scales and transformations when hit-testing the non-fast scrollable region in cc. If yes, we should close this bug and work in Chromium instead.

That sounds a bit more forward-thinking to me.  The important thing is knowing which space these are in.

[Tien-Ren Chen]

(In reply to comment #2)
> (In reply to comment #1)
> > Discussed with Tien-Ren. Perhaps we should not scale in WebKit, but should apply required scales and transformations when hit-testing the non-fast scrollable region in cc. If yes, we should close this bug and work in Chromium instead.
> 
> That sounds a bit more forward-thinking to me.  The important thing is knowing which space these are in.

My opinion is that those should be always in the layer's local coordinate.
WebKit is not supposed to know too much about the page scale factor in the new model. (also WebKit has no way to know the scale delta, so we have to do the scale in the compositor anyway)

[Tien-Ren Chen]

*** This bug has been marked as a duplicate of bug 105075 ***