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

Issue 842258 link

Starred by 1 user

Issue metadata

Status: Duplicate
Merged: issue 749349
Owner:
Closed: May 2018
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows
Pri: 2
Type: Bug-Regression



Sign in to add a comment

When dir=rtl, element is being rendered to the right of where it should be

Reported by jgru...@gmail.com, May 11 2018

Issue description

UserAgent: Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/66.0.3359.139 Safari/537.36

Steps to reproduce the problem:
Here is a JSFiddle that shows the problem: https://jsfiddle.net/nuLjayw1/2/

1. dir=rtl
2. outermost div has position: relative, overflow: hidden, z-index: 1
3. next div has position: fixed, overflow-y: auto
4. innermost div has position: relative and is large enough to overflow its parent

What is the expected behavior?

What went wrong?
The innermost div is being rendered 17px to the right of where it should be, but pointer events aren't lined up with the rendered element, but rather with where the element is supposed to be.

Did this work before? N/A 

Does this work in other browsers? Yes

Chrome version: 66.0.3359.139  Channel: n/a
OS Version: 10.0
Flash Version: 

This bug doesn't happen on Firefox, Edge, or IE 11.
 

Comment 1 by phistuck@gmail.com, May 11 2018

Components: -Blink>CSS Blink>Layout
Labels: -Type-Bug -Pri-2 Needs-Bisect Pri-1 Type-Bug-Regression
Status: Untriaged (was: Unconfirmed)
Worked in Chrome 59, failed since Chrome 60, only on Windows.
macOS and Android are fine. I have not tried Linux.
Cc: susan.boorgula@chromium.org
Labels: -Pri-1 -Needs-Bisect -Type-Bug-Regression M-68 Triaged-ET FoundIn-68 Target-68 OS-Linux Pri-2 Type-Bug
jgrucza@ Thanks for the issue.

Able to reproduce the issue on Windows 10 and Ubuntu 14.04 on the latest Canary 68.0.3429.0 and Stable 66.0.3359.170.
Issue is not observed on Mac OS 10.13.3.

On navigating to the given JSFiddle link,can observe that the innermost div is shifted to the right.
Attached is the screen shot for reference.

This is a Non-Regression issue as this behavior is observed from M60 Chrome builds. 
Requesting Dev to look into this issue and help in further triaging.

Thanks..
842258-M60.PNG
97.7 KB View Download
Labels: Needs-Bisect
#2 - can you find which revision caused this, though? I wrote in comment 1 that Chrome 60 broke it. Chrome 59 is fine.
Thank you.
Cc: glebl@chromium.org phistuck@chromium.org
Labels: -Type-Bug -Needs-Bisect hasbisect Type-Bug-Regression
Owner: ikilpatrick@chromium.org
Status: Assigned (was: Untriaged)
//Adding to comment #2

Bisect Information:
===================
Good Build: 60.0.3096.0 (Revision - 470759)
Bad Build : 60.0.3097.0 (Revision - 471158)

Unable to execute the per-revision bisect script as all good builds were invoking. Hence below is the manual Changelog URL by from omahaproxy:

https://chromium.googlesource.com/chromium/src/+log/60.0.3096.0..60.0.3097.0?pretty=fuller&n=10000

From the above Changelog, suspecting the below change:
Reviewed-on: https://codereview.chromium.org/2850893003

As the owner of the CL - glebl@ is not available for the last 30 days, assigning the issue to reviewer ikilpatrick@ for further help.

ikilpatrick@ Please check and confirm if this issue is related to your change, else help us in assigning to the right owner.

Thanks
Cc: -phistuck@chromium.org ikilpatrick@chromium.org
Owner: yigu@chromium.org
That change list only touched LayoutNG code, so I doubt it is related.
However, this change list touched positioning code -
https://chromium.googlesource.com/chromium/src/+/fca776d5b4979b1f9d86926bfb6d3fb14a0343f3

@yigu - can you take a look? Thank you.

Comment 6 by yigu@chromium.org, May 14 2018

Mergedinto: 749349
Status: Duplicate (was: Assigned)

Sign in to add a comment