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

Issue 128500 link

Starred by 14 users

Issue metadata

Status: Fixed
Last visit > 30 days ago
Closed: Feb 2016
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 2
Type: Bug

Blocked on:
issue 179332

Sign in to add a comment

Wrong clientLeft value for RTL direction, while the element have vertical scrollbar in left side.

Reported by, May 17 2012

Issue description

Chrome Version       : 19.0.1084.46 m
OS Version: 6.1 (Windows 7, Windows Server 2008 R2)
URLs (if applicable) :
Other browsers tested:
  Firefox 4.x:OK 
     IE 7/8/9:OK 

In  19.0.1084.46 m version onwards, the  left scrollbar for RTL direction was introduced . Because of this change the related clentLeft property is not giving value including scrollbar width .

What steps will reproduce the problem?
1.Create a div  with RTL direction and vertical scroll . 
2.Get clientLeft value .

What is the expected result?
Should be the border left width + scrollbar width

What happens instead?
clientLeft value returns only the border left width and not including scrollbar width


Comment 1 by, May 18 2012

Labels: -Area-Undefined Area-WebKit WebKit-RTL

Comment 2 by, May 18 2012

Labels: -OS-Windows OS-All
Can you please attach a minimal testcase?

Bono-san: any insight into this issue?

Comment 3 by, May 18 2012


Thanks for your bug report.
I have written a test that shows the clientLeft property and it becomes 0 on Chrome. (This value becomes 17 on Firefox 12.0 and 0 on IE9.) In my honest opinion, I have not touched any code affecting to the clientLeft property since I could not find clear description for the clientLeft values of RTL elements. (IE9 mirrors the coordinate for RTL elements and it makes sense that the clientLeft value becomes 0 on IE.)


Hironori Bono
405 bytes View Download
These are my findings and according to w3c specification, this is a bug.

"The clientLeft attribute returns the computed value of the 'border-left-width' property plus the width of any scrollbar rendered between the left padding edge and the left border edge."

Dottor0 - Web Reference:
"If the vertical scrollbar is rendered and it is on the left side of the element, the clientLeft property returns the width of the left border and plus the width of the scrollbar in Internet Explorer. If the value of the direction property is 'rtl' and the vertical scrollbar needs to be rendered, then the vertical scrollbar will appear on the left side of the element."

1. Chrome 19.0.1084.46 m    - Wrong 
2. Firefox 12.0				- Correct
3. IE 9						- Wrong
4. IE 8						- Wrong
5. IE 7						- Correct
6. IE 6						- Correct

Comment 5 by, May 18 2012

Status: Available

Thanks for your reference. It definitely helps convincing WebKit people. :)


Hironori Bono

Comment 6 by Deleted ...@, Oct 22 2012

Any advances on this issue?
Still having this bug in Chrome 22.0.1229.94 m
Does anyone have an explanation for the change in IE behavior between IE7 and IE8, apparently violating a standard that they had up to now observed (given that generally they have been trying to observe standards more closely in IE8 and IE9)?

Hironori wrote: "IE9 mirrors the coordinate for RTL elements and it makes sense that the clientLeft value becomes 0 on IE." What do you mean by "coordinate" here?
Have you talked to anyone on the IE team about this? Any chance it's just a bug or oversight on their part?
I am not in real contact with anyone on IE. Wish I were...
Project Member

Comment 10 by, Mar 10 2013

Labels: -Area-WebKit -WebKit-RTL Cr-Content-RTL Cr-Content
Project Member

Comment 11 by, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 12 by, Apr 6 2013

Labels: -Cr-Content-RTL Cr-Blink-RTL
Labels: WebKit-ID-85856
THere is activity on this bug in WebKit, which should be moved here. The WebKit bug is closed.
Owner: ----
Project Member

Comment 15 by, May 20 2013

Labels: -WebKit-ID-85856 WebKit-Rev-123067 WebKit-ID-85856-RESOLVED

Comment 16 by, Jun 17 2013

You recently commented on the WebKit bug. Is this bug affecting a Google property? Are you aware of the Chrome move to Blink?
I am aware of the Chrome move to Blink. However, Google products still need to support Safari.

This bug was found in the context of Trix (Google Docs spreadsheets). I am not sure if a workaround was implemented or if there is still a visible issue there.

Project Member

Comment 18 by, Jun 19 2013

Labels: -WebKit-ID-85856-RESOLVED WebKit-ID-85856-REOPENED

Project Member

Comment 19 by, Jul 16 2013

Labels: -WebKit-ID-85856-REOPENED WebKit-ID-85856-RESOLVED

This is just a bad compat bug as a result of our left-side scrollbar work. :(

Comment 21 by, Oct 28 2013

I'll take this one.

Comment 22 by, Oct 30 2013

Mergedinto: 179332
Status: Duplicate
Sanjoy has a working patch for this on a related bug.

Comment 23 by, Oct 30 2013

Status: Assigned
Actually, his fixes the more parts, but not the actual client left. I'll take care of that once his patch lands.

Comment 24 by, Oct 30 2013

s/more/more egregious/
Blockedon: chromium:179332
(according to #23)

Comment 26 Deleted

The patch on  issue 179332  landed, unclear if that means it's fixed or not. :)
Looks fixed to me in 33.0.1708.0 canary on Win 7.
Its not fixed by the patch on  issue 179332 . I have uploaded patch to fix this issue
What isn't fixed by the patch on 179332?
The bug/behavior posted at comment#4 is not fixed by the patch on   issue 179332 . Blink/WebKit's current behavior matches neither FF or IE. The patch makes blink match FF and old IE, but not new IE.
Sounds good!
It looks like the patch from comment #31 just failed to land.  I've clicked the CQ checkbox again, but Sanjoy may need to update it for it to land cleanly.
looks like scrollIntoView is also still broke in canary:
Can this be marked as fixed?
Labels: -Cr-Blink
Removing Cr-Blink from issues that already have Cr-Blink sub-label set.

Comment 39 by, Feb 18 2016

Status: Fixed

Sign in to add a comment