1926971 - Navbar on joyous.team doesn't work

Status: RESOLVED WORKSFORME

(Web Compatibility :: Site Reports, defect, P3)

Description

[Jeff Muizelaar [:jrmuizel]]

Attachment: Standalone test case

Hover or clicking on "Treatment plan", "The Science", etc. does nothing.

Comment 1

[Jeff Muizelaar [:jrmuizel]]

Attachment: Somewhat reduced test case

Comment 2

[Jeff Muizelaar [:jrmuizel]]

Interestingly Safari has similar behaviour to FF on the reduced test case but not on the standalone test case.

Comment 3

[Daniel Holbert [:dholbert]]

Using the "Standalone test case", it looks like this used to work (the layout ended up a bit different, too, but that's independent of this behavior-change where e.g. hover state gets seemingly-ignored).

Last good revision: ab4ccf3d6b60 (2013-09-18)
First bad revision: 803189f35921 (2013-09-19)
Pushlog:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=ab4ccf3d6b60&tochange=803189f35921

In that range, I suspect this would've been from bug 904197 (about sticky-positioning), given that this testcase does have position:sticky in a rule for .top-nav-bar.

[EDIT: I can make this broken in older Nightlies if I replace sticky with relative in the testcase. Sticky-positioning is a form of relative positioning, and it looks like our initial sticky-position impl happened to have a bug that inadvertently worked around this compat issue, and this^ regression range is when we fixed that bug.]

Comment 4

[Daniel Holbert [:dholbert]]

(In reply to Jeff Muizelaar [:jrmuizel] from comment #2)

Interestingly Safari has similar behaviour to FF on the reduced test case but not on the standalone test case.

I spun off bug 1928223 for a further-reduced version of the reduced-test-case here (which I initially marked as a blocker for this bug, but now I think should probably be considered independent). Interestingly, Chrome 100 and earlier behaves just like Safari on both testcases here and on bug 1928223. (i.e. Chrome 100 matches Firefox on the reduced testcase but not on the standalone testcase.)

I'll work on getting a better reduction of the Standalone test case that captures the important behavior-difference here.

Comment 5

[Daniel Holbert [:dholbert]]

Attachment: testcase 3

Here's a further-reduced testcase, where I've swapped sticky-positioning to relative-positioning (simpler/older) and made various other simplifications. There are two orange rects; the first doesn't have z-index set at all, whereas the second has z-index set on the inline-level wrapper element.

STR: try hovering each of the orange rects and see if they change color.

• Firefox: neither rect changes color.
• WebKit: only the lower rect changes color when hovered (i.e. WebKit needs z-index to be set on the display:inline wrapper in order for that rect to be sufficiently-in-the-foreground to be hoverable)
• Chrome: both rects change color (individually) when they are hovered.

The fact that z-index makes a difference in WebKit feels like it might be related to the discussion in bug 1573990 (i.e. https://bugs.webkit.org/show_bug.cgi?id=274903 )

Comment 6

[Daniel Holbert [:dholbert]]

As with other testcases discussed here, Chrome 100 (old) matches WebKit on testcase 3, whereas Chrome 101-and-newer match current Chrome (v132 dev)

Comment 7

[Daniel Holbert [:dholbert]]

Interesting observation: on testcase 3, very-old-Firefox honors the hover-state only on the upper rect. But that doesn't seem to be relevant to the actual site here. But for the record, the regression range for that change (when we got our current behavior of not-honoring-hover-state-for-either-rect in testcase 3):
Last good revision: 82b6c5885345 (2012-07-23)
First bad revision: a26e751bfb54 (2012-07-24)
Pushlog: http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=82b6c5885345&tochange=a26e751bfb54

In that range, I'd suspect bug 772690 is what would've caused this behavior-change (though again, that's not relevant to the actual site here, in part because the actual site uses sticky-positioning which we didn't support at that point).

Comment 8

[Daniel Holbert [:dholbert]]

I'm suspicious that this is a version of [EDIT: fixing bug typo] bug 1899829 -- marking as such. I think this is probably related to the stacking-order difference demonstrated by testcase 2 over there.

I'll post my just-attached testcase as an additional one over there, to be sure it's on the radar of whoever works on that bug (and we can spin off a followup if it turns out that the fix doesn't address this case).

Comment 9

[Daniel Holbert [:dholbert]]

We could conceivably deploy an intervention here. Here's one possible intervention that seems to work locally without any side effects that I've noticed. (This just nerfs a pseudo-element that's empty and only-present-as-a-clear:both clearfix type of hack, which doesn't seem to be necessary as far as I've seen.)

.top-nav-bar-container > .w-container::after {
  display: none;
}

Comment 10

[Thomas Wisniewski [:twisniewski]]

I think the site has since changed their layout, as I can click on the top menubar entries without any issue on my Macbook. Dan, Jeff, could either of you confirm?

Comment 11

[Daniel Holbert [:dholbert]]

yup, seems to have been fixed-by-site-redesign.

I can still reproduce using this wayback-machine snapshot:
https://web.archive.org/web/20241102013902/https://www.joyous.team/
(note, you have to click the "x" on the wayback-machine header-overlay at the top, in order to see the navbar in question)

But I can't reproduce on the current version of the site, whose layout/content looks quite different.