The element's offset isn't relevant when comparing its dimensions with that of its overflow

The element's offset isn't relevant when comparing its dimensions with that of its overflow

The offset isn't relevant for these functions. Use of the offset was introduced
by https://chromium.googlesource.com/chromium/src/+/10b0fc70b6e2383d439a83917541fe073b1e34e5

As far as I can tell we still don't have a test for it, so I don't think the
change is correct - makes no sense to me that the position of an object should
be considered when comparing the rect used to represent its overflow with the
rect used to represent its dimensions. It won't make any difference unless some
scaling is done on the object and then it leads to invalid differences.

BUG=619509

[rhogan, 2016-07-13 18:37:44]

Description was changed from

==========
The element's offset isn't relevant when comparing its dimensions with that of
its overflow

BUG=619509
==========

to

==========
The element's offset isn't relevant when comparing its dimensions with that of
its overflow

The offset isn't relevant for these functions. Use of the offset was introduced
by
https://chromium.googlesource.com/chromium/src/+/10b0fc70b6e2383d439a83917541...

As far as I can tell we still don't have a test for it, so I don't think the
change is correct - makes no sense to me that the position of an object should
be considered when comparing the rect used to represent its overflow with the
rect used to represent its dimensions.

BUG=619509
==========

[rhogan, 2016-07-13 18:39:04]

Description was changed from

==========
The element's offset isn't relevant when comparing its dimensions with that of
its overflow

The offset isn't relevant for these functions. Use of the offset was introduced
by
https://chromium.googlesource.com/chromium/src/+/10b0fc70b6e2383d439a83917541...

As far as I can tell we still don't have a test for it, so I don't think the
change is correct - makes no sense to me that the position of an object should
be considered when comparing the rect used to represent its overflow with the
rect used to represent its dimensions.

BUG=619509
==========

to

==========
The element's offset isn't relevant when comparing its dimensions with that of
its overflow

The offset isn't relevant for these functions. Use of the offset was introduced
by
https://chromium.googlesource.com/chromium/src/+/10b0fc70b6e2383d439a83917541...

As far as I can tell we still don't have a test for it, so I don't think the
change is correct - makes no sense to me that the position of an object should
be considered when comparing the rect used to represent its overflow with the
rect used to represent its dimensions. It won't make any difference unless some
scaling is done on the object and then it leads to invalid differences.

BUG=619509
==========

[rhogan, 2016-07-13 18:39:49]

robhogan@gmail.com changed reviewers:
+ eae@chromium.org

[eae, 2016-07-13 20:18:33]

https://codereview.chromium.org/2074353002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2074353002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:453: return
snapSizeToPixel(clientWidth(), clientLeft());
The location is needed to correctly snap the client and offset widths/heights or
it will not match where it is painted.

The width/height does depend on the location. The easiest way to illustrate this
is to imagine a set of repeating inline boxes with a width of 10.5px. Ever other
one will snap to 10px and 11px respectively. This to ensure that the total width
of all of them is as close to (n * 10.5px) as possible.

It is not, however, needed for the overflow rect.

[rhogan, 2016-07-17 18:37:45]

https://codereview.chromium.org/2074353002/diff/20001/third_party/WebKit/Sour...
File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):

https://codereview.chromium.org/2074353002/diff/20001/third_party/WebKit/Sour...
third_party/WebKit/Source/core/layout/LayoutBox.cpp:453: return
snapSizeToPixel(clientWidth(), clientLeft());
On 2016/07/13 at 20:18:33, eae wrote:
> The location is needed to correctly snap the client and offset widths/heights
or it will not match where it is painted.
> 
> The width/height does depend on the location. The easiest way to illustrate
this is to imagine a set of repeating inline boxes with a width of 10.5px. Ever
other one will snap to 10px and 11px respectively. This to ensure that the total
width of all of them is as close to (n * 10.5px) as possible.
> 
> It is not, however, needed for the overflow rect.

OK, so do we have to live with a scrollbar on this guy?

<div style="top: 87.5px; height: 448.75px; overflow: auto; position: absolute;">
    <div style="height: 449px;">
        <div style="height: 1px; width: 1px;"></div>
    </div>
</div>

[eae, 2016-07-18 16:35:30]

On 2016/07/17 18:37:45, rhogan wrote:
>
https://codereview.chromium.org/2074353002/diff/20001/third_party/WebKit/Sour...
> File third_party/WebKit/Source/core/layout/LayoutBox.cpp (right):
> 
>
https://codereview.chromium.org/2074353002/diff/20001/third_party/WebKit/Sour...
> third_party/WebKit/Source/core/layout/LayoutBox.cpp:453: return
> snapSizeToPixel(clientWidth(), clientLeft());
> On 2016/07/13 at 20:18:33, eae wrote:
> > The location is needed to correctly snap the client and offset
widths/heights
> or it will not match where it is painted.
> > 
> > The width/height does depend on the location. The easiest way to illustrate
> this is to imagine a set of repeating inline boxes with a width of 10.5px.
Ever
> other one will snap to 10px and 11px respectively. This to ensure that the
total
> width of all of them is as close to (n * 10.5px) as possible.
> > 
> > It is not, however, needed for the overflow rect.
> 
> OK, so do we have to live with a scrollbar on this guy?
> 
> <div style="top: 87.5px; height: 448.75px; overflow: auto; position:
absolute;">
>     <div style="height: 449px;">
>         <div style="height: 1px; width: 1px;"></div>
>     </div>
> </div>

Yeah, probably. The inner element is, after all, taller than the container.
If we can find a way to avoid a scrollbar there without breaking the other case
that would be great but none immediately comes to mind :(