New issue
Advanced search Search tips

Issue 894234 link

Starred by 1 user

Issue metadata

Status: Fixed
Owner:
Closed: Jan 7
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 3
Type: Bug



Sign in to add a comment

Layout with has one extra pixel width on MacOs

Project Member Reported by maxlg@chromium.org, Oct 10

Issue description

https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/image_paint_timing_detector_test.cc?q=image_paint_timing+package:%5Echromium$&dr=C&l=127

When I was writing this test case, I discover that the layout object on the MacOS always has one extra pixel in width.

For example, when h*w = 5*6, the size result becomes 37; when h*x = 7*10, the size result becomes 77.

The size result in the test is not completely the layout size. It's the layout size that get transformed and intersected with viewport size. Extra work will be needed to tell whether the transform and intersecting have played a role in it.
 
Cc: chrishtr@chromium.org
+Chris,

I notice that one of your tests also shows a similar behavior, not sure whether you know something about it?
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/paint_layer_clipper_test.cc?type=cs&q=%23if%5Csdefined%5C(OS_MACOSX%5C)+f:test%5C.cc+f:paint&g=0&l=301
Components: Blink>Paint
The code I wrote that you linked to is about the control clip of a native-rendered select element.

But are you testing such a situation? I think the link you gave may be out of date. What case are you
testing?
I also use #ifdef here.
https://cs.chromium.org/chromium/src/third_party/blink/renderer/core/paint/image_paint_timing_detector_test.cc?q=image_paint_timing+package:%5Echromium$&dr=C&l=304

I was testing the image size. When we set an image of a certain size, the layout size will turn out to be one pixel larger in width, in MacOs only. This looks like the same issue with yours.
Status: Available (was: Untriaged)
chrishtr@, I'm marking this available, let me know if you disagree.
Owner: maxlg@chromium.org
Status: Assigned (was: Available)
The issue is due to font heights of inlines being platform-dependent.

<img> is by default display:inline, which causes it to use vertical positioning
according to the "font" that is used by its inline range.

You can fix it easily by changing the images to display:block in your unittest.
Status: Started (was: Assigned)
Project Member

Comment 7 by bugdroid1@chromium.org, Jan 7

The following revision refers to this bug:
  https://chromium.googlesource.com/chromium/src.git/+/2e7cb796ead3315ea3795ac7813e89da23e0d27a

commit 2e7cb796ead3315ea3795ac7813e89da23e0d27a
Author: Liquan(Max) Gu <maxlg@chromium.org>
Date: Mon Jan 07 20:12:24 2019

[FCP++] Set Display:block to image paint unit tests

As the font heights of inlines is platform-dependent, the height of image in
Mac and other platform are determined differently.

<img> is by default display:inline, which causes it to use vertical positioning
according to the "font" that is used by its inline range. As a result, the
unittest shows different height for the image on different platform.

To fix it, I change the images to display:block in the unittest.

Bug:  894234 
Change-Id: I43a582ee41e1bacb3025e2487135e2cbf0a69887
Reviewed-on: https://chromium-review.googlesource.com/c/1398520
Reviewed-by: Steve Kobes <skobes@chromium.org>
Commit-Queue: Liquan (Max) Gu <maxlg@chromium.org>
Cr-Commit-Position: refs/heads/master@{#620443}
[modify] https://crrev.com/2e7cb796ead3315ea3795ac7813e89da23e0d27a/third_party/blink/renderer/core/paint/image_paint_timing_detector_test.cc

Status: Fixed (was: Started)
Thanks Chris, the problem has been fixed:)

Sign in to add a comment