New issue
Advanced search Search tips

Issue 833167 link

Starred by 3 users

Issue metadata

Status: Fixed
Closed: Aug 31
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug-Regression

issue 823365

Sign in to add a comment

Absolutely positioned box is misaligned in vertical layout inside iframe

Reported by, Apr 15 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:61.0) Gecko/20100101 Firefox/61.0

Steps to reproduce the problem:
See an attached file or visit

What is the expected behavior?
Left edge of the fixed element touches left edge of viewport.

What went wrong?
There is 17px gap (same as width of vertical scrollbar) between left edge of the fixed element and left edge of viewport.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 68.0.3397.0  Channel: canary
OS Version: 10.0
Flash Version: Shockwave Flash
577 bytes View Download
1.9 KB View Download

Comment 1 by, Apr 15 2018

Bisected to 96f85b68747a679ea1ac4cd05d6743ae5f7142b7 
"Enable root layer scrolling."
Landed in 66.0.3345.0

Confirmed by disabling the CL and observing the bug is gone:
chrome --disable-blink-features=RootLayerScrolling

Bisected the underlying bug to 5549f27a280edeaea35d8e55e9ffae0c9d5e3a54 
"More fixes for position:fixed with root layer scrolling."
Landed in 45.0.2447.0
Command line used to force-enable RLS feature in all versions of Chrome:
chrome --enable-blink-features=RootLayerScrolling --root-layer-scrolls
Labels: Needs-Triage-M68
Labels: -Type-Bug -Pri-2 FoundIn-66 Target-67 Triaged-ET FoundIn-67 M-66 Target-66 ReleaseBlock-Stable Target-68 RegressedIn-66 FoundIn-68 hasbisect OS-Linux Pri-1 Type-Bug-Regression
Status: Assigned (was: Unconfirmed)
Able to reproduce the issue on reported chrome version 68.0.3397.0 and on the latest canary 68.0.3399.0 using Windows 10 and Ubuntu 14.04.
Note: Issue is not seen on Mac 10.13.1

Bisect Information:
Last Good Build: 66.0.3344.0
First Bad Build: 66.0.3345.0

Suspecting the same from Comment#1.

Review URL:

Note: Adding RB-stable as this seems to be a recent regression, please remove if not required.

@Steve Kobes: Please help in assigning it to the right owner if this is not related to your change.

Comment 4 by, Apr 19 2018

Blocking: 823365
Labels: -Pri-1 -ReleaseBlock-Stable Pri-2
This issue happens outside iframe if CSS properties that may cause hardware acceleration, such as `animation` or `transform: translateZ(0)`, are applied to the absolutely positioned element itself or its descendants.

I filed  issue 835555  for the case outside iframe but that issue may be a duplicate of this issue.
 Issue 835555  has been merged into this issue.
Status: Started (was: Assigned)
A non-RLS repro:

LayoutBox::FlipForWritingModeForChild uses border box width which includes the scrollbar.  But the child's Location().X() is relative to the right edge of the client area (scrolling content).
Just tried the test in #c7 and found it has been fixed by The #c0 issue still exists.

Owner: ----
Status: Available (was: Started)
Thanks for the update.  I'm afraid I don't have bandwidth to fix this right now so I am marking it available.
Labels: -M-66 -Target-66 -Target-67 -Target-68 -Needs-Triage-M68 Target-70 M-70
Status: Assigned (was: Available)
The fix for  bug 853945  might also fix this bug. Moving target to M-70.
Project Member

Comment 11 by, Aug 31

The following revision refers to this bug:

commit d44db9636279ee5238407ea776dbaab82cfd5363
Author: Xianzhu Wang <>
Date: Fri Aug 31 23:08:16 2018

[PE] Fix LayoutBox Client/Padding/Content boxes with scrollbars (especially vertical-rl)

This CL tries to correct the box model when there are scrollbars,
especially in vertical-rl mode. According to, scrollbars
"should be inserted between the inner border edge and the outer
padding edge".

Changes to the previous code:

- Padding|client box now excludes scrollbars, with the help of
  (Top|Left|Bottom|Right)ScrollbarWidth methods which can get the
  scrollbar widths in physical directions in various writing modes.

- Content box is now based on the new padding box by excluding the

- Layout of contents is now based on the correct box model. In
  vertical-rl mode, layout of contents in blocks direction starts
  from the inner edge of the new content box which has been properly
  adjusted for the scrollbar.

- Now LayoutBox::Location() and Location::PhysicalLocation() in the
  initial scroll state are correct in all writing-modes. Previously
  when they were incorrect in vertical-rl mode and some flex box
  directions, requiring an artificial scroll offset to paint the
  content at correct place.

- With the correct padding box, content box, Location(),
  PhysicalLocation(), we no longer need the band-aid code to create the
  correct painted result.

The changed code is mostly in LegacyLayout code. Some changed code is
in LayoutNG that previously converted correct LayoutNG geometries into
the problematic geometries that were previously expected by

The correct box model is required by blink-gen-property-trees because
we can't band-aid the incorrect results in paint properties after

Bug:  833167 , 853945 , 858843 , 878809 , 876266 

Cq-Include-Trybots: luci.chromium.try:linux_layout_tests_slimming_paint_v2;luci.chromium.try:linux-blink-gen-property-trees;luci.chromium.try:linux_layout_tests_layout_ng;master.tryserver.blink:linux_trusty_blink_rel
Change-Id: I41faf1ca0bfb95cb287c72703f08c8bd44e9e752
Reviewed-by: Morten Stenshorne <>
Reviewed-by: Christian Biesinger <>
Cr-Commit-Position: refs/heads/master@{#588201}

Status: Fixed (was: Assigned)
Verified the fix on Ubuntu 14.04 using Chrome version #71.0.3541.0 as per the comment #0.
Note: Couldn't verify the fix on Windows 10 as the build isn't available yet.
Attaching screenshot for reference.
Observed the alignment was proper.
Hence, the fix is working as expected. 
Note: Able to reproduce the issue on chrome version with out fix.

833167 CL Verification.png
187 KB View Download

Sign in to add a comment