1593538 - position:absolute + position:sticky and position bug during scrolling

Status: RESOLVED DUPLICATE of bug 1472602

(Core :: Layout: Positioned, defect, P3)

Description

[Nadia]

User Agent: Mozilla/5.0 (Windows NT 6.3; rv:68.0) Gecko/20100101 Firefox/68.0

Steps to reproduce:

• Open https://output.jsbin.com/gavonexuve/1/
• Set windows width 400px
• Scroll window down and up multiple times.
• The yellow rectangle has bad position.

You need stronker programmers. ;-) Similar problem was reported and is marked as fixed. But the problem still exists.

Btw. The CSS3 spec needs improvement. I must use shadows to remove scrollbar creating without overflow:hidden.

68.2.0esr (32 bity)
In Chrome works correctly.

Actual results:

Bad rectangle has bad position.

Expected results:

No changing in position of yellow rectangle after scroll up.

Comment 1

[Emilio Cobos Álvarez [:emilio]]

Attachment: Testcase from reporter.

Comment 2

[Emilio Cobos Álvarez [:emilio]]

I need to say I'm a bit confused about what you're trying to accomplish with position: sticky in that test-case.

I would expect the tooltip to stick to the viewport, however no other browser does that. Firefox kinda tries to do it, poorly (only when you force a re-layout somehow it goes to some previous offset).

But I would say that the behavior you expect (which I guess is the tooltip not moving or something? at least that's what I see in Chrome, in which you claim that works correctly) is not expected either, you should probably be using position: relative or such.

Mind clarifying the behavior you expect?

Similar problem was reported and is marked as fixed.

Can you point to that bug?

Comment 3

[Nadia]

I need to say I'm a bit confused about what you're trying to accomplish with position: sticky in that test-case.

Emulation of non-existing "min-left" and "min-right" ;-) It is my "dirty" hack for tooltip hints. Please try to resize window to left and to right slowly and please observe :-) Without scripts! In my projects it works with :focus or :hover or both. :-) The hint is never shown outside the text container and isn't clipped. The shadow hack is used to stop creating the horizontal scrollbar.

however no other browser does that

It works correctly (due to the spec) in Brave and Chrome and please copy correct behaviour . Doesn't work in IE11 (due to not implemented sticky - JS workaround if "Trident" detected), not tested in EDGE.

Workaround for Firefox 68 is:

top:auto; /* instead of 0 */
bottom:auto; 

for my use case.

Can you point to that bug?

I need some time to find it again. I accidentally found it, looking for a solution to another problem. Any problem with sticky and table-row and table-cell positioning.

Comment 4

[Nadia]

Can you point to that bug?

It is probably this bug https://bugzilla.mozilla.org/show_bug.cgi?id=1528957 . I have no Firefox 60.5 to check it. But description is similar and is marked as... VERIFIED FIXED :-/ But not fixed for sticky tables. Please also test for flexes, tables, table-rows, table-cells, table-captions, inline-blocks etc.. Solution for ONE type of elements is no solution.

Comment 5

[Emilio Cobos Álvarez [:emilio]]

It works correctly (due to the spec) in Brave and Chrome and please copy correct behaviour

Can you quote the spec text that makes the other browser's behavior correct out of curiosity? Brave and Chrome are the same engine effectively so it's not any sort of proof that they're correct.

Anyhow, there's clearly a bug in Gecko as the incremental computation shouldn't differ from the regular one.

Comment 6

[Nadia]

Can you quote the spec text that makes the other browser's behavior correct out of curiosity?

"For stickily positioned elements, left, right, top and bottom are offsets from the respective edges of its flow box which are used to constrain the element’s offset. Percentage values of left and right refer to the width of its flow box; percentage values of top and bottom refer to the height of its flow box."

"A rectangle is computed relative to the containing block of the stickily positioned element, by insetting its flow box rectangle on each side by offsets computed from the left, right, top and bottom properties of the stickily positioned element. "

https://www.w3.org/TR/css-position-3/#sticky-pos

Thus after scrolling down and return to the top of document the position should be unchanged. (see attachment). It looks like the position is partially calculated relative to scrolling box instead "flow box" / "containing block" (height of containing block in this case is equal to height of sticky element and there should be no vertical sticky effect, only horizontal should be). Firefox does it bugly, chrome does it correctly.

Is this amount of information sufficient?

Comment 7

[Nadia]

Attachment: sticky+absolute positioning bug in firefox

Comment 8

[Emilio Cobos Álvarez [:emilio]]

Thus after scrolling down and return to the top of document the position should be unchanged.

Sure, that I agree with, obviously.

height of containing block in this case is equal to height of sticky element and there should be no vertical sticky effect, only horizontal should be

This one I don't agree with so obviously though. The height of the sticky element inseted by the offsets is still the height of the sticky element, not the height of the containing block.

The main difference here, I think, is that Chrome and other browsers seem to be interpretting the top: 0, bottom: 0 as regular position: absolute boxes do, but not how regular position: relative boxes do. Sticky in that sense is more similar to position: relative.

Comment 9

[Nadia]

In the nutshell, this function works correctly (i can describe it worngly because i'm not native english speaker) except of the horrible scrolling effect after scrolling up.

I don't know what other problems has Blinky (Chromium). I test only my solutions (and i'm furious if I find unstable behaviour), I don't test Firefox or Chrome. Unstable behavior is worse than almost standard behavior because often cannot be corrected with other CSS styles.

It is very strange, that if the sticky element jump,. further resizing of window or scrolling doesn't repair it. It isn't strictly drawing problem. It is dynamic positioning problem.

BTW.

ill-considered new CSS styles can also make me frustrated. New style for only one application (here for "floating" headers, trying to use for hints needs a lot of hacks).

Also:

• New display: flow-root, also only for one use-case ... I'd better see it as overflow: flow-root / * hidden without clipping ;-) * /
• Floating elements with defined edge (non-rectangular) still not available.
• <select/> without possibility of styling the ::dropdown-menu... (still I must use radiobutton+label hack. In 2019).
• Scrollbars without possibility of styling width, arrows etc (CSSWG doesn't accept chrome or chrome-like pseudoelements that are intuitive... CSSWG accepted IE model).

I think, they (CSSWG) really need stronker developers, not Mozilla. ;-) To many styles, too few possibilities and real use-cases, to many dependences.

Comment 10

[Gregory Pappas [:gregp]]

I think this was fixed by bug 1472602. What do you think?

Comment 11

[BugBot [:suhaib / :marco/ :calixte]]

Redirect a needinfo that is pending on an inactive user to the triage owner.
:dholbert, since the bug has recent activity, could you have a look please?

For more information, please visit auto_nag documentation.