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
Owner:
Last visit > 30 days ago
Closed: Feb 2016
Cc:
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 gelansel...@cordys.com, 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 tkent@chromium.org, May 18 2012

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

Comment 2 by jeremy@chromium.org, May 18 2012

Cc: aharon.l...@gmail.com
Labels: -OS-Windows OS-All
Owner: hbono@chromium.org
Can you please attach a minimal testcase?

Bono-san: any insight into this issue?

Comment 3 by hbono@chromium.org, May 18 2012

Greetings,

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.)

Regards,

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

clientLeft:

w3c.org: http://www.w3.org/TR/cssom-view/
"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: http://help.dottoro.com/ljwsjkop.php
"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."

Tested:
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 hbono@chromium.org, May 18 2012

Status: Available
Greetings,

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

Regards,

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 bugdroid1@chromium.org, Mar 10 2013

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

Comment 11 by bugdroid1@chromium.org, Apr 6 2013

Labels: -Cr-Content Cr-Blink
Project Member

Comment 12 by bugdroid1@chromium.org, 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.
Cc: hbono@chromium.org
Owner: ----
Project Member

Comment 15 by bugdroid1@chromium.org, May 20 2013

Labels: -WebKit-ID-85856 WebKit-Rev-123067 WebKit-ID-85856-RESOLVED
https://bugs.webkit.org/show_bug.cgi?id=85856
http://trac.webkit.org/changeset/123067

Comment 16 by pdr@chromium.org, Jun 17 2013

Aharon,
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 bugdroid1@chromium.org, Jun 19 2013

Labels: -WebKit-ID-85856-RESOLVED WebKit-ID-85856-REOPENED
https://bugs.webkit.org/show_bug.cgi?id=85856

Project Member

Comment 19 by bugdroid1@chromium.org, Jul 16 2013

Labels: -WebKit-ID-85856-REOPENED WebKit-ID-85856-RESOLVED
https://bugs.webkit.org/show_bug.cgi?id=85856

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

Comment 21 by le...@chromium.org, Oct 28 2013

Cc: igo...@sisa.samsung.com eseidel@chromium.org
Owner: le...@chromium.org
I'll take this one.

Comment 22 by le...@chromium.org, Oct 30 2013

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

Comment 23 by le...@chromium.org, Oct 30 2013

Cc: sanjoy....@samsung.com
Mergedinto:
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 le...@chromium.org, 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 https://codereview.chromium.org/70163005/.
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 https://codereview.chromium.org/70163005/ 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:
http://plnkr.co/UZvnlq
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 le...@chromium.org, Feb 18 2016

Status: Fixed

Sign in to add a comment