Closed Bug 1472602 Opened 6 years ago Closed 2 years ago

Sticky postioned table-caption elements draw at wrong position after scrolling back up

Categories

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

61 Branch
defect

Tracking

()

RESOLVED FIXED
102 Branch
Tracking Status
firefox-esr91 --- wontfix
firefox100 --- wontfix
firefox101 --- wontfix
firefox102 --- fixed

People

(Reporter: m.gamper, Assigned: emilio)

References

(Blocks 1 open bug)

Details

(Keywords: regression)

Attachments

(4 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.13; rv:63.0) Gecko/20100101 Firefox/63.0
Build ID: 20180701220749

Steps to reproduce:

A table's caption element who is positioned sticky works fine if I scroll down. If I scroll up, the element remains in it's last position and covers the table element.


Actual results:

 If I scroll up, the element remains in it's last position and covers parts of the table element.


Expected results:

The caption element sould stay sticky until it reached is original position where it should scroll with the rest of the content.
Do you have a link to the HTML, or an HTML testcase you could attach?
Component: CSS Parsing and Computation → Layout
I can reproduce this using the codepen.

mozregression got me this range, which is where this testcase goes from "no sticky positioning at all" to "broken sticky positioning":
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0843e4e6cb1d6e32a35ce4d7014bd250c24f74fa&tochange=d20967c26da559a7781db467741bb240af9bfe5c

That indicates that this started when bug 975644 landed (that's where we added support for sticky-positioned table captions).
Blocks: 975644
Status: UNCONFIRMED → NEW
Ever confirmed: true
Summary: Sticky postioned caption elements won't work if scrolling up → Sticky postioned table-caption elements won't work if scrolling up
Attached file testcase 1
Attachment #8990825 - Attachment description: (helper for testcase 1) → testcase 1
Attachment #8990827 - Attachment description: testcase 1 → testcase 2 (with testcase 2 in an iframe)
I find it's a bit easier to trigger the problem when using attachment 8990827 [details] (the version with an iframe).

However, I can trigger it with the standalone file (attachment 8990825 [details]) if I simply scroll down & back to the top, and then switch to a different tab and back.

So -- this seems to be an invalidation bug of some sort.
Priority: -- → P3
Summary: Sticky postioned table-caption elements won't work if scrolling up → Sticky postioned table-caption elements draw at wrong position after scrolling back up

I’ve run into the same bug, see https://codepen.io/gunnarbittersmann/pen/PoOeKvO?editors=0100

Is there some work-around until this bug will eventuelly be fixed?

(In reply to gunnar@bittersmann.de from comment #7)

I’ve run into the same bug, see https://codepen.io/gunnarbittersmann/pen/PoOeKvO?editors=0100

Is there some work-around until this bug will eventuelly be fixed?

I have found one:

<style>
    @keyframes chwidth {
        0% { width: 100%; } 50% { width: 0%; } 100% { width: 100%; }
    }
    .chwidth {
        max-width: 0;
        animation: 1s chwidth infinite;
    }
</style>
<table>
    <caption style="position:sticky;top:0">SomeCaption<div class="chwidth"></div></caption>
    <tr><td>someval1</td><td>someval2</td></tr>
</table>

The animation does nothing, but makes ff think changes are large enough to force an invalidation every frame.
This works very reliably for scrolling with the scrollbar or gestures. For scrolling using the mouse weel the caption jumps around somewhat, which is visually iritating but otherwise harmless.

If I understand correctly sticky when scrolling is mostly dealt with in APZ, but feel free to bounce back if this ends up being a layout bug after all...

Component: Layout → Panning and Zooming

Actually looking a bit deeper into it it does look like a layout bug.

Component: Panning and Zooming → Layout: Positioned
Assignee: nobody → emilio
Flags: needinfo?(emilio)

Captions should be relatively-positioned (other browsers support this as
well). This ensures we correctly save their normal positions and thus
that the sticky scroll container knows how to reposition them correctly.

Avoid registering inner table frames with the sticky scroll container to
make the assertion sound in cases of sticky-positioned tables.

Flags: needinfo?(emilio)
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/e3377838e213
Sticky/relative position fixes in nsTableWrapperFrame. r=dholbert
Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34174 for changes under testing/web-platform/tests

Backed out for causing multiple failures related to StickyScrollContainer.

Push with failures

Failure log for debug-crashtest
Failure log for reftest
Failure log for wpt

Backout link

Flags: needinfo?(emilio)
Upstream PR was closed without merging
Pushed by ealvarez@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/cf63538fe82c
Sticky/relative position fixes in nsTableWrapperFrame. r=dholbert
Status: NEW → RESOLVED
Closed: 2 years ago
Resolution: --- → FIXED
Target Milestone: --- → 102 Branch
Upstream PR merged by moz-wptsync-bot
Flags: needinfo?(emilio)
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: