2033384 - congresoseed.com - Page header does not have a fixed position and disappears when scrolling

Status: VERIFIED FIXED

(Core :: Layout, defect, P1)

Description

[Raul Bucata]

Attachment: Chr vs ff

Environment:
Operating system: Linux and Windows 10
Firefox version: Firefox 149.0.2 (release)

Preconditions:

• Clean profile

Steps to reproduce:

1. Navigate to: https://congresoseed.com/
2. Scroll up and down and observe

Expected Behavior:
The page header has a fixed position

Actual Behavior:
The page header disappears

Notes:

• Reproducible on the latest Firefox Release and Nightly
• Reproducible regardless of the ETP setting
• Works as expected using Chrome

---

Created from webcompat-user-report:12d75528-37e6-44c8-9144-d03fdb114520

Comment 1

[Raul Bucata]

Refreshing the page makes the header appear again, but the issue still reproduces when scrolling is performed

Comment 2

[Alice0775 White]

Regression window:
https://hg-edge.mozilla.org/integration/autoland/pushloghtml?fromchange=f0508bdfdcef4a7f203806f510d1fa084224aedb&tochange=4dc50e8367a1d9082bc8f8fa8296481ec97a2ba4

Comment 3

[BugBot [:suhaib / :marco]]

:emilio, since you are the author of the regressor, bug 2008148, could you take a look? Also, could you set the severity field?

For more information, please visit BugBot documentation.

Comment 4

[Emilio Cobos Álvarez [:emilio]]

Attachment: Reduced test-case.

People always find a creative use of display: table-column, wtf?

Comment 5

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2033384 - Tweak colgroup child suppression. r=#layout

This code comes all the way back from bug 480979.

What happens here is as follows:

• There are two table-column items, with their relevant anonymous
  wrapper. Why the page uses display: table-column for this escapes
  my understanding.
• We insert the header next to them. We compute the parent frame to be
  the (anonymous) nsTableColumnGroup frame, because it's our sibling's
  parent.
• We decide you're not a column, and thus you get suppressed. We don't
  create FrameConstructionItems for it.
• We don't realize in WipeContainingBlock that things went wrong, and
  fail miserably.

Fortunately we don't seem to need this anymore. Make this go through the
regular code-path.

We could keep this check with an !IsAnonymous() sort-of check but...

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://github.com/mozilla-firefox/firefox/commit/9f8191aba14c
https://hg.mozilla.org/integration/autoland/rev/04fbcab6ec35
Tweak colgroup child suppression. r=layout-reviewers,dshin

Comment 7

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

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

Comment 8

[Norisz Fay [:noriszfay]]

https://hg.mozilla.org/mozilla-central/rev/04fbcab6ec35

Comment 9

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

Upstream PR merged by moz-wptsync-bot

Comment 10

[Donal Meehan [:dmeehan]]

:emilio, do you want to request a beta uplift?

Comment 11

[Phabricator Automation]

firefox-beta Uplift Approval Request

• User impact if declined/Reason for urgency: Fixes webcompat regression
• Code covered by automated testing?: yes
• Fix verified in Nightly?: yes
• Needs manual QE testing?: yes
• Steps to reproduce for manual QE testing: comment 0
• Risk associated with taking this patch: low
• Explanation of risk level: Relatively scoped change.
• String changes made/needed?: none
• Is Android affected?: yes

Comment 12

[Emilio Cobos Álvarez [:emilio]]

Attachment: Bug 2033384 - Tweak colgroup child suppression.

This code comes all the way back from bug 480979.

What happens here is as follows:

• There are two table-column items, with their relevant anonymous
  wrapper. Why the page uses display: table-column for this escapes
  my understanding.
• We insert the header next to them. We compute the parent frame to be
  the (anonymous) nsTableColumnGroup frame, because it's our sibling's
  parent.
• We decide you're not a column, and thus you get suppressed. We don't
  create FrameConstructionItems for it.
• We don't realize in WipeContainingBlock that things went wrong, and
  fail miserably.

Fortunately we can tweak this to perform the suppression later in the
pipeline.

Original Revision: https://phabricator.services.mozilla.com/D295265

Comment 13

[Emilio Cobos Álvarez [:emilio]]

Guess it's safe enough, yeah.

Comment 14

[BugBot [:suhaib / :marco]]

Set release status flags based on info from the regressing bug 2008148

Comment 15

[Pulsebot]

https://github.com/mozilla-firefox/firefox/commit/39faabfea64d
https://hg.mozilla.org/releases/mozilla-beta/rev/e003345e56c3

Comment 16

[Alin Ilea, Desktop Test Engineering]

Reproduced the issue in Release 149.0.2
Verified - Fixed in Beta 151.0b2(build id: 20260423122027) and Nightly 152.0a1(build id: 20260423082823). The page header remains fixed.
Leaving the bug status unchanged for now, since firefox150 tracking flag is fix-optional.