Change:
<ins> // The goal of this test is to ensure that the tooltip `.information` class doesn't // have overflow and max-width CSS rules set because they create a bug in firefox on // mac. For more information: https://github.com/rust-lang/rust/issues/89185 goto: file://|DOC_PATH|/test_docs/fn.foo.html assert-css: (".docblock > .information", { "overflow-x": "visible", "max-width": "none" }, ALL) </ins>

Discussion:
It looks like it's inheriting for some reason. ! !
cc
Assigning priority as discussed in the of the Prioritization Working Group. label -I-prioritize +P-high
I couldn't replicate locally on Windows (both Edge 93 and Firefox 92 seems to render it correctly).
I'm using Firefox, so at least my version does not render it correctly :) I'm using the latest stable version of Firefox on macOS.
I checked in Chrome on macOS and it renders correctly, so it seems like the situation is this:
I haven't bisected, but I'm pretty sure this was caused by the following code in : could you look into this bug? It'd be good to get it fixed since it makes the UI confusing. I don't have enough knowledge of rustdoc's CSS to try to fix it myself right now.
adds a horizontal scrollbar (overflow-x) though, the scrollbar that appears on the screenshot is a vertical one. The information box has no explicit height set so there is no reason that it should overflow. The scrollbar makes no sense to me, I wonder if this is a browser bug...
For me, Chrome Version 94.0.4606.81 (Official Build) (64-bit) and Firefox 93.0 (64-bit) on Linux both render correctly. do you have any extensions installed? Does it reproduce in a fresh Firefox profile?
I do not have extensions installed, and yes, it reproduces with a fresh profile. See my table above (); it seems like it may be specific to Firefox on macOS.
Just tested on my mac. The problem seems to be firefox because there is no overflow rule on the item and yet firefox says there is. Also we can scroll the first paragraph of the docblock. Well in short, firefox seems to be completely broken...
What do you mean? Chrome shows the same overflow rule that Firefox does, but the scrollbar bug is not present in Chrome. The following is the rule I'm talking about; are you describing a different one? I don't see any scrollbars other than for the icons and the whole page. What are you referring to?
Taking screenshots on mac when you maintain something is a nightmare so I didn't but you can scroll the first paragraph of a docblock (even though there is no scrollbar).

As for the tooltip icon, it's not a direct child of so this rule isn't applied to it.
Ah, my computer mouse does not have a scroll wheel, so I don't have a way to test the scrolling you're describing.
It is a direct child of , which is why the rule is applied ( is the container for the icon): !
Touchpad powa! The tooltip is inside , so the scroll isn't applied to it directly (which is what I meant), but its parent has it, indeed. I guess we were saying the same thing. :3 This is a very interesting bug though.
Yeah, I think this might be both a Firefox and a rustdoc bug
Let's cut the apple in two: it's 100% Firefox's bug. We can now happily close this issue and move on with our lives knowing we were not wrong. :smiley_cat:
Hehe, this bug really drives me nuts though. And I imagine it bothers everyone else who uses Firefox on macOS to read rustdoc docs :) I'd imagine there's a way for us to workaround this bug, though, right? I could file a Firefox bug, but I don't know how to minimize this.
It works mostly fine on my (old) mac, so it's hard for me to try anything... Can you try to add a on the scroll/overflow rules?
Yeah, that fixes it. It's kind of a hack, but I guess it's better than the current situation. Do you want to open a PR or should I?
As you prefer!
Oh before I forget: if you send a PR, don't forget to add a GUI test to check that there is no overflow/scroll rule on it please. :) If you haven't sent a PR tomorrow, I'll send one. ;)
But GUI tests are run in Chromium, right? Is this just to make sure we don't have a bug for all browsers?
I think I might not have time to send a PR, but I'm happy to review it if you open a PR :)
The goal here is just to ensure that the CSS rules which cause the bug in firefox aren't applied on . So the browser doesn't matter. Then I'll send one tomorrow. Thanks in advance for the review!