New issue
Advanced search Search tips

Issue 759284 link

Starred by 1 user

Issue metadata

Status: Assigned
Owner:
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: Linux , Windows , Mac
Pri: 3
Type: Bug-Regression



Sign in to add a comment

position:sticky with display:inline-block is bugged

Reported by sirvalen...@gmail.com, Aug 26 2017

Issue description

Chrome Version       : 60.0.3112.113 (Windows)
URLs (if applicable) : https://jsfiddle.net/h7hm4agj/4/
Other browsers tested:
              Firefox: OK
 Canary (62.0.3189.0): FAIL

What steps will reproduce the problem?
(1) Navigate to https://jsfiddle.net/h7hm4agj/4/
    OR open the attached test.html in the browser directly
(2) Scroll down inside the bordered div area where a pink square resides,
    so that the pink square sticks to the top as position:sticky obligates it.
(3) Resize the browser window !horizontally!.
(4) The pink square should have glitched out, jumping down in it's parent div.
(5) When you scroll in the parent div now, the pink square should stay fixed
    in the position where it jumped when window resized, ignoring all
    scrolling actions.

(6) To *fix* the pink square and restore it's original behavior scroll inside
    the parent back up to the top and resize the window again. The pink square
    should now jump to it's original location, and again behave like it is
    supposed to according to position:sticky.


What is the expected result?
  Pink square should not jump around when a resize update happens,
  but continue on its duty as a display:sticky styled element.


What happens instead?
  As stated above, it jumps down
  IF it is currently sticking to the top of it's parent
  AND the viewport is resized.

Please provide any additional information below. Attach a screenshot if
possible.
  Originally discovered for the <img> tag, where it would behave like
  the pink square in the example above. I supposed however, and it seems
  to be correct, that any element with display:inline-block would behave this way.

  The screenshot compilation of the bug is attached as pinksquare.png

 
test.html
433 bytes View Download
pinksquare.png
102 KB View Download
Cc: pnangunoori@chromium.org
Components: Blink>Layout
Labels: -Type-Bug Needs-Triage-M60 hasbisect-per-revision M-62 OS-Linux OS-Mac OS-Windows Type-Bug-Regression
Owner: flackr@chromium.org
Status: Assigned (was: Unconfirmed)
Tested on Chrome Stable #60.0.3112.113, Canary #62.0.3197.0 and able to reproduce the issue on Windows 7, Mac 10.12.6 and Ubuntu 14.04.

Using the per-revision bisect providing the bisect results,
Good build: 58.0.2992.0 (445908)
Bad build: 58.0.2993.0  (446204) 

You are probably looking for a change made after 484746 (known good), but no later than 484758 (first known bad).

CHANGELOG URL:
The script might not always return single CL as suspect as some perf builds might get missing due to failure.

https://chromium.googlesource.com/chromium/src/+/686dbbef585fd2064f1a2a3451b90e501936a589

From the CL above, assigning the issue to the concern owner

@flackr: Could you please look into the issue, pardon me if it has nothing to do with your changes and if possible please assign it to concernd owner.

Review-URL: https://codereview.chromium.org/2646133002

Comment 2 by e...@chromium.org, Aug 30 2017

Components: -Blink>Layout Blink>Scroll

Comment 3 by bor...@gmail.com, Nov 20 2017

This might be related. I have found the problem to occur on display: table-cell as well.

Changing display to `grid` on the scrolling element fixes the issue.

Here is a example showing the problem:
https://codepen.io/anagrius/pen/GOQQqy

Comment 4 Deleted

Though it's funny this happens due to inline-block, I've seen similar issues in Firefox and safari, when (like here) the scrolling element is also the nearest block level ancestor for the sticky element to use as a containing block.

If you wrap the contents inside another element effectively separating the 'scrollport' and the 'scrollbox' into two elements you can work around the bug.

Sign in to add a comment