New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 784003 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Android , Windows , Chrome , Mac
Pri: 2
Type: Bug



Sign in to add a comment

Blink incorrectly uses LayoutBox::Location() to snap PaintLayer size

Project Member Reported by szager@chromium.org, Nov 10 2017

Issue description

As discussed in this CL:

https://chromium-review.googlesource.com/c/chromium/src/+/752030

PaintLayer::PixelSnappedSize() uses Box().Location() to do the snapping, but Box().Location() is not the same as paint offset.

There are four places where layer size comes into play:

1) Determining overflow -- PaintLayerScrollableArea::Has(Horizontal|Vertical)Overflow

2) Determining clip rects -- PaintLayerClipper::CaluclateRects

3) Positioning overflow controls for paint -- PaintLayerScrollableArea::PositionOverflowControls

4) Hit testing -- PaintLayerScrollableArea::HitTestOverflowControls

Currently, all of these use a layer size snapped to box.Location(), but they *should* all use the accumulated paint offset for snapping.  That offset is available to the clipping code (2), and could be plumbed into the overflow control positioning code (3) fairly easily.  Passing it to overflow computation (1) and hit testing (4) will be harder.

The worst thing that can happen with the current code is that layer size will be off by one pixel; so not the end of the world, but still not correct.
 
Labels: OS-Android OS-Chrome OS-Linux OS-Mac OS-Windows
Owner: chrishtr@chromium.org
Status: Assigned (was: Untriaged)
Tentatively assigning to chrishtr@ for case (2) and maybe (3).

Comment 2 by szager@chromium.org, Nov 13 2017

Just to be clear: we can't fix this piecemeal.  All of the use cases would need to switch at the same time.

Sign in to add a comment