Closed Bug 1528957 Opened 8 months ago Closed 5 months ago

The sticky position works wrongly for table-row elements

Categories

(Core :: Web Painting, defect, P3)

65 Branch
x86
Windows
defect

Tracking

()

VERIFIED FIXED
mozilla69
Tracking Status
firefox-esr60 --- wontfix
firefox67 --- wontfix
firefox68 --- wontfix
firefox69 --- verified

People

(Reporter: arisa-2, Assigned: mattwoodrow)

References

(Regression)

Details

(Keywords: regression)

Attachments

(1 file)

User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:60.0) Gecko/20100101 Firefox/60.0

Steps to reproduce:

he sticky in tables still work incorectly on table-row elements...
https://jsfiddle.net/sj5xb39c/

Why does the sticky layer disappeared after 30 seconds??? What part of spec define this behaviour?

Versions: Firefox for windows: 60.5.1 and 65 affected.

Actual results:

The sticky layer disappeared

Blocks: 975644
Keywords: regression
OS: Unspecified → Windows
Priority: -- → P4
Hardware: Unspecified → x86
Status: UNCONFIRMED → NEW
Component: Untriaged → Layout: Tables
Ever confirmed: true
Priority: P4 → P3
Product: Firefox → Core

Workaround for Firefox 60.5.1:
.header
{
display:table-row-group;
}

Seems like a painting bug. Switching window visibility a bit (changing to other windows that cover up this one, then changing back) makes the sticky row paint again.

Flags: needinfo?(matt.woodrow)

Next test (without workaround). table-caption also affected but other effect.

https://jsfiddle.net/f6r2dptu/3/

I timed it, and the sticky row disappears after 15 seconds, which is the same as apz.displayport_expiry_ms.

Looks like we remove the displayport due to inactivity, and that breaks painting of the sticky content.

Component: Layout: Tables → Web Painting

It looks like nsTableRowGroupFrame::BuildDisplayList, DisplayRows, and nsTableRowGroupFrame::GetFirstRowContaining are all using the 'normal' position of the row to decide if we should build display items.

In the broken case, the sticky content is on screen, but it's 'normal' (without position:relative/sticky applied) is offscreen. So we're deciding not to display it.

I think this code is from before we supported position:relative properly, and should just be changed to use the visual overflow rect like we do normally.

Assignee: nobody → matt.woodrow
Flags: needinfo?(matt.woodrow)
Duplicate of this bug: 1504444
Pushed by mwoodrow@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/a0195a554c70
Use the frame's rect to advance nsTableRowGroupFrame's cursor, since that's what the max overflow values are computed relative to. r=emilio
Status: NEW → RESOLVED
Closed: 5 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla69

Is this something we should consider backporting to Beta ahead of the next ESR?

No longer blocks: 975644
Flags: needinfo?(matt.woodrow)
Regressed by: 975644
Flags: qe-verify+

I don't think we need to, it's a long standing issue, and this patch is part of a larger table painting rewrite (that I don't want to risk uplifting).

Flags: needinfo?(matt.woodrow)

Verified - Fixed on latest Nightly 69.0a1 (2019-06-12) (64-bit) on Windows 10, Mac OS 10.13 and Ubuntu 18.04.
The sticky layer remains displayed.

Status: RESOLVED → VERIFIED
Flags: qe-verify+
You need to log in before you can comment on or make changes to this bug.