DevRel-SAP: Unexpected padding-right in RTL when block has a scrollbar
Reported by
pavelkor...@gmail.com,
Apr 13 2018
|
||||||||||||||
Issue descriptionWhat is the version of Chrome (chrome://settings/help)? Version 67.0.3395.0 (Official Build) canary (64-bit) What is the OS Version? OSX 10.13.3 (17D47), but the problem is also reproducible on Windows. What are the steps to reproduce the problem? 1. Create a page in RTL mode; 2. Define custom styling for the scrollbar; 3. Create a block with a scrollbar inside + position relative/absolute; 4. Create an inner block with bigger size to make a scrollbar available in outer block; 5. Create a third block inside the inner block and assign position absolute to it; 6. Observe default behavior - the block is shifted; 7. Set translateX to zero => same behaviour as default - block is shifted; 8. Instead of translateX, set "right: 0" - the block is on the correct position. What is the expected behavior? 1. no extra padding is added OR possibility to disable/remove this padding via CSS; 2. translateX and "right: 0" calculate coordinates on the ViewPort consistently. What is the experienced behavior? In RTL mode, in case when there are custom styles for a scrollbar, Chrome adds extra padding from the right side. Then if there are elements with position absolute/fixed inside, their position calculates based on the adjusted block width and there is no way to remove this padding (see screenshot Chrome.png): 1. "right: 0" works normally 2. "transform: translate(0, 0)" works incorrectly 3. default (without "translate" and "right" specified) works incorrectly Live demo: https://jsbin.com/vexunetefa/1/edit?html,output Is the experienced behavior different in other browsers? Also reproducible in Safari, but other browsers like FireFox, IE11, Edge are fine (see screenshot Edge.png).
,
Apr 13 2018
DevTools matches the painted location, so for now assuming this is layout related and not paint related. But we may also be getting the transformed layer in the wrong spot.
,
Apr 16 2018
,
Apr 19 2018
Able to reproduce this issue on reported version 67.0.3395.0 , on latest stable 66.0.3359.117 and on latest canary 68.0.3399.0 using Windows 10, Mac 10.13.3 and Ubuntu 14.04. This issue is seen from M-60. Hence considering this issue as Non-Regression and marking as Untriaged.
,
Apr 26 2018
,
Apr 30 2018
,
Jun 29 2018
Is this issue going to be fixed?
,
Jul 4
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/25c0bbd3266427e2a2d28ddf6a9c94198798b20b commit 25c0bbd3266427e2a2d28ddf6a9c94198798b20b Author: Stefan Zager <szager@chromium.org> Date: Wed Jul 04 11:15:35 2018 Adjust out-of-flow position for rtl container with left-hand scrollbar BUG=832569 R=mstenshoe@chromium.org,eae@chromium.org Change-Id: I3405923d394b4d14a509ac28d84358ca6a58e846 Reviewed-on: https://chromium-review.googlesource.com/1125335 Commit-Queue: Stefan Zager <szager@chromium.org> Reviewed-by: Emil A Eklund <eae@chromium.org> Cr-Commit-Position: refs/heads/master@{#572536} [add] https://crrev.com/25c0bbd3266427e2a2d28ddf6a9c94198798b20b/third_party/WebKit/LayoutTests/fast/block/rtl-abs-pos-container-with-scrollbar-expected.html [add] https://crrev.com/25c0bbd3266427e2a2d28ddf6a9c94198798b20b/third_party/WebKit/LayoutTests/fast/block/rtl-abs-pos-container-with-scrollbar.html [modify] https://crrev.com/25c0bbd3266427e2a2d28ddf6a9c94198798b20b/third_party/blink/renderer/core/layout/layout_box.cc
,
Jul 5
Can this be merged to M68 and/or M69? Thanks.
,
Jul 5
This bug requires manual review: We don't branch M69 until 2018-07-19. Please contact the milestone owner if you have questions. Owners: amineer@(Android), kariahda@(iOS), cindyb@(ChromeOS), govind@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 5
This bug requires manual review: M68 has already been promoted to the beta branch, so this requires manual review Please contact the milestone owner if you have questions. Owners: cmasso@(Android), kariahda@(iOS), bhthompson@(ChromeOS), abdulsyed@(Desktop) For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 5
OK! Removing Merge-Review-69 because it hasn't branched yet.
,
Jul 6
How safe is this merge? It's been around since M67 seems like, can we wait until M69 then?
,
Jul 6
It is safe to merge.
,
Jul 10
Approved -branch:3440
,
Jul 16
This issue has been approved for a merge. Please merge the fix to any appropriate branches as soon as possible! If all merges have been completed, please remove any remaining Merge-Approved labels from this issue. Thanks for your time! To disable nags, add the Disable-Nags label. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jul 18
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/9da8bdde6d8c874d957e9d39dd7977de02840612 commit 9da8bdde6d8c874d957e9d39dd7977de02840612 Author: Stefan Zager <szager@chromium.org> Date: Wed Jul 18 00:06:51 2018 Adjust out-of-flow position for rtl container with left-hand scrollbar Cherry-picked from: https://chromium-review.googlesource.com/1125335 BUG=832569 TBR=mstenshoe@chromium.org,eae@chromium.org Change-Id: I7d2f26800ed5a410b0cca9bb61bf7529c2298536 Reviewed-on: https://chromium-review.googlesource.com/1141213 Reviewed-by: Stefan Zager <szager@chromium.org> Cr-Commit-Position: refs/branch-heads/3440@{#709} Cr-Branched-From: 010ddcfda246975d194964ccf20038ebbdec6084-refs/heads/master@{#561733} [add] https://crrev.com/9da8bdde6d8c874d957e9d39dd7977de02840612/third_party/WebKit/LayoutTests/fast/block/rtl-abs-pos-container-with-scrollbar-expected.html [add] https://crrev.com/9da8bdde6d8c874d957e9d39dd7977de02840612/third_party/WebKit/LayoutTests/fast/block/rtl-abs-pos-container-with-scrollbar.html [modify] https://crrev.com/9da8bdde6d8c874d957e9d39dd7977de02840612/third_party/blink/renderer/core/layout/layout_box.cc
,
Jul 25
Hi, I believe that issue was not completely fixed. The extra padding for elements with custom scrollbars is still there and you can't control it. You can see it in the Chrome Developer Tools. The positioning of elements with relative/absolute position is correctly calculated now, but there are still cases when the issue occurs. I describe it below: What is the version of Chrome (chrome://settings/help)? Both: Version 68.0.3440.68 (Official Build) beta (64-bit) Version 70.0.3501.2 (Official Build) canary (64-bit) What is the OS Version? macOS 10.13.6 Windows 10 Pro Version 1803 What are the steps to reproduce the problem? 1. Create a page in RTL mode; 2. Define custom styling for the scrollbar; 3. Create a block with a scrollbar inside + position relative/absolute; and add z-index:1; to the block to create a stacking context 4. Create an inner block with bigger size to make a scrollbar available in outer block; 5. Create a third block inside the inner block and assign position: absolute; and will-change: transform; to it 6. Observe default behavior - the block is shifted 7. Remove z-index: 1; from the first block - the third block goes back to its expected position 8. Instead of removing z-index: 1; remove will-change: transform; from the third block - the third block goes back to its original position What is expected behaviour? 1. No extra padding is added to the container OR possibility to disable/remove this padding via CSS; 2. The position of the third element is calculated consistently when z-index and will-change are applied. What is the experienced behavior? In RTL mode, in case when there are custom styles for a scrollbar, Chrome adds extra padding from the right side of the container. If the container has a z-index property and if its children have will-change property, their position is wrongly calculated and off by the extra padding on the container. Link to demo: [https://jsbin.com/qewobunoka/1/edit?html,output](https://jsbin.com/qewobunoka/1/edit?html,output) I tested the same code in Firefox and Edge and both browsers don't add the extra padding to the container element.
,
Jul 25
Both of your new examples are fixed when running the latest chromium code, most likely by this recent commit: https://chromium-review.googlesource.com/c/chromium/src/+/1141332 That commit should appear in Chrome canary within a couple of days.
,
Jul 26
szager, thanks for the update, I will check it out!
,
Aug 2
#19 - it would be great if you also made sure http://jsfiddle.net/0b5nptt5/ is fixed.
,
Aug 2
,
Sep 10
There seems to be a few issues left. As far as I can see the test case in http://jsfiddle.net/0b5nptt5/ is now fixed though. But looking at that test case and checking devtools, it will show incorrect position of elements (see attachment). There is also still an issue with this together with layers or `overflow: overlay`. I'm attaching another test case where this is shown. This is tricky to test in latest Chrome though, as there seems to be a regression for this bug: https://bugs.chromium.org/p/chromium/issues/detail?id=250514 I was testing this in Chromium 68.0.3440.106. |
||||||||||||||
►
Sign in to add a comment |
||||||||||||||
Comment 1 by poromov@chromium.org
, Apr 13 2018