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

Status: RESOLVED FIXED

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

Description

[Mathias Gamper]

Attachment: Bildschirmfoto 2018-07-02 um 08.14.50.png

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.

Comment 1

[David Baron :dbaron: (⌚️UTC-4, no longer working on Mozilla)]

Do you have a link to the HTML, or an HTML testcase you could attach?

Comment 2

[Mathias Gamper]

Here's a live example:
https://www.frauenfeld.ch/politik-verwaltung/verwaltung/online-schalter.html/344/l/de

And an isolated test case is here:
https://codepen.io/macgamper/pen/mKvoyL

Comment 3

[Daniel Holbert [:dholbert]]

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

Comment 4

[Daniel Holbert [:dholbert]]

Attachment: testcase 1

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 2 (with testcase 2 in an iframe)

Comment 6

[Daniel Holbert [:dholbert]]

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.

Comment 7

[[e-mail]]

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?

Comment 8

[Redjard]

(In reply to [e-mail] 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.

Comment 9

[Emilio Cobos Álvarez (:emilio)]

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

Comment 10

[Emilio Cobos Álvarez (:emilio)]

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

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Attachment: Bug 1472602 - Sticky/relative position fixes in nsTableWrapperFrame. r=dholbert

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.

Comment 12

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/e3377838e213
Sticky/relative position fixes in nsTableWrapperFrame. r=dholbert

Comment 13

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Created web-platform-tests PR https://github.com/web-platform-tests/wpt/pull/34174 for changes under testing/web-platform/tests

Comment 14

[Iulian Moraru]

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

Comment 15

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR was closed without merging

Comment 16

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/cf63538fe82c
Sticky/relative position fixes in nsTableWrapperFrame. r=dholbert

Comment 17

[bszekely]

https://hg.mozilla.org/mozilla-central/rev/cf63538fe82c

Comment 18

[Web Platform Test Sync Bot [:wpt-sync] (Matrix: #interop:mozilla.org)]

Upstream PR merged by moz-wptsync-bot