1895051 - "目录" (Directory) button in www.zhihu.com answer is unclickable

Status: REOPENED

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

Description

[Tom25519]

Steps to reproduce:

1. Open an answer in zhihu.com which has "目录" (Directory) button, for example, https://www.zhihu.com/question/609483004/answer/3102943695, https://www.zhihu.com/question/597728323.
2. Click "目录" (Directory).

Actual results:

It's unclickable on Firefox, but Edge not.

Expected results:

This bug shouldn't appear.

Comment 1

[Tom25519]

Attachment: Directory button.png

Comment 2

[Alice0775 White]

Adding the following CSS seems to work around the problem.

.css-h7wqi8 {
   z-index:2;
}

Comment 3

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Screenshot (Chrome, Firefox, Edge, Edge after clicking 目录).png

I made a screenshot. From left to right is Google Chrome, Firefox, Edge, and Edge after clicking 目录 (Directory).

I don't see a behavior difference between Google Chrome and Firefox. Even though I cannot click "目录" (Directory), but I can click "收起" (fold). It will turn into "展开目录" (expand directory), which is clickable.

On edge, the site is implement differently. "目录" (Directory) is clickable, but after clicking "目录", a popup containing the sections is covering the page.

Comment 4

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Tom25519, thanks for reporting the bug. Per my observation in comment 3, I'm not convinced this is a Firefox bug. I do agree the site can be easier to use if they made the entire box containing "目录" (Directory) clickable. I'm going to close this bug, but feel free to let me know if I missed anything.

Comment 5

[Alice0775 White]

:TYLin,
You should test this under narrower width of browser and the open the site, so that the page layout will be as same as Edge).
Then, attempt to click The button 目录.

Firefox: The button appears under comment text and images, so it not clickable.
Chrome/Edge: The button appears top of comment text and images, and clickable as same as Edge.

Comment 6

[Alice0775 White]

Attachment: screenshot Chome vs Nightly

Comment 7

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Indeed, I can reproduce the bug with narrow browser window width. Thanks!

Comment 8

[Dennis Schubert [:denschub]]

Let's move this into the Site Reports component to do diagnosis here and figure out why this is broken.

Comment 9

[Daniel Holbert [:dholbert]]

Has the site layout changed such that this doesn't reproduce anymore?

On the two URLs in comment 0:
(1) On the first one, I'm not seeing a 目录 button at all (and find-in-page doesn't find any results for that text)
(2) On the second one, I do see some 目录 UI but it's not overlapping the article content at all (it doesn't look like comment 6) -- instead, for me, that UI seems to be off to the left of the article content (even if I make my browser skinnier, which just pushes it entirely offscreen).

I tested at a bunch of viewport-sizes in Firefox and Chrome, and I'm seeing these results (not anything like comment 6).

Can anyone still repro? (and if so, do you have any ideas about what might be causing our differential results? Not sure if there's a geographic component [I'm in California] or if this requires a login, or something else.)

Tagging TYLin to check since he was the most recent to say he could repro. :) Thanks!

Comment 10

[Daniel Holbert [:dholbert]]

(Further evidence for the site potentially having been redesigned to remove/reimplement the problematic content: if I put the string css-h7wqi8 (from comment 2) into the "Search html" box in DevTools Inspector, I'm not seeing any matches, in either of the two pages linked in comment 0.)

Comment 11

[Alice0775 White]

I can still reproduce the issue on Nightly129.0a1 Windows11.
And the CSS selector css-h7wqi8 can be found in the inspector.

STR:

1. Make browser width 1200px
2. Open https://www.zhihu.com/question/597728323 . And close dialog box if any.

Comment 12

[Ting-Yu Lin [:TYLin] (PDT, UTC-7)]

Attachment: Screenshot on Firefox Nightly 129

I can still reproduce this bug on the second one after shrinking the browser window until <html> width is around 800px. I need to refresh the page to make the 目录 button appear.

Comment 13

[Jeff Muizelaar [:jrmuizel]]

Are you still unable to reproduce?

Comment 14

[Daniel Holbert [:dholbert]]

I can reproduce, yeah. I'll see if I can create a reduced testcase later today. (The testcase-reducer add-on isn't capturing the issue here for some reason; not sure why offhand.)

The element here (circled in red in comment 12) seems to be a sticky-positioned element, and it's got a different visual-stacking-order in Firefox vs. Chrome. As I scroll down the page, it gets covered up by various content in Firefox, vs. it's superimposed in front of the content in Chrome.

(Side note, for reference when testing the URLs here: they seem to sometimes trigger a splash page that I have to click through and then complete a captcha, which then redirects to a login page, which I can then disregard and then successfully load the original URL again, to end up looking at the actual page.)

Comment 15

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 1

Here's a somewhat-reduced testcase. I'll post a further-reduced testcase shortly.

Comment 16

[Daniel Holbert [:dholbert]]

Attachment: screenshot comparing Firefox (left) to Chrome (right) on reduced testcase 1

Comment 17

[Daniel Holbert [:dholbert]]

WebKit (epiphany on Ubuntu 22.04) matches Firefox on the original site and on the attached testcase, for what it's worth. So this is either a case of a Chrome bug that the site is inadvertently depending on, or there's a painting-order bug that Firefox/WebKit happen to share.

Comment 18

[Daniel Holbert [:dholbert]]

Attachment: reduced testcase 2

(In reply to Daniel Holbert [:dholbert] from comment #14)

The element here (circled in red in comment 12) seems to be a sticky-positioned element, and it's got a different visual-stacking-order in Firefox vs. Chrome.

Actually the more relevant element is an ancestor which is absolutely positioned, not this sticky-positioned one.

Its containing block happens to be display:inline from this rule:

.css-376mun {
  position: relative;
  display: inline;
}

And that makes Gecko/WebKit disagree with Chromium about the stacking order for its abspos descendants vs. later in-flow descendants, as shown in this attached testcase.

In this testcase, Gecko and WebKit render the blue div in front, whereas Chromium renders the orange div in front.

Comment 19

[Daniel Holbert [:dholbert]]

This might be tangentially related to https://github.com/w3c/csswg-drafts/issues/8284 (which is also associated with bug 489100); all of these are about display:inline serving as an abspos containing block.

Comment 20

[Daniel Holbert [:dholbert]]

There's a trivial workaround for the site that we could in theory ship as a sitepatch here (or suggest to the site) -- we/they just need to remove the display:inline declaration from the .css-376mun rule that I quoted in comment 18 (or override it with display:block).

With that CSS tweak, this button stacks in the foreground and is visible/clickable, just as the site intends for it to be.

Comment 21

[Daniel Holbert [:dholbert]]

--> removing webcompat:needs-diagnosis given the above. I've spun off bug 1915992 as the underlying platform bug on our side (to the extent that this is a Gecko bug)

Comment 22

[Daniel Holbert [:dholbert]]

(In reply to Daniel Holbert [:dholbert] from comment #17)

WebKit (epiphany on Ubuntu 22.04) matches Firefox on the original site and on the attached testcase, for what it's worth. So this is either a case of a Chrome bug that the site is inadvertently depending on, or there's a painting-order bug that Firefox/WebKit happen to share.

Following up on this: I think Chrome's behavior is what the spec calls for, per bug 1915992 comment 9.