This is likely to be partly the result of bugs in the site, but some amount of investigation would be appreciated.

STR:

1. Open any document on https://docs.google.com/
2. Open the font menu, it should have scroll bars (if not, make the window shorter)
3. Hover over a font with a ► icon
4. Attempt to select a font weight from that menu

What happens:

If your font menu has many fonts in it, there will be a scrollbar on the right. When your mouse passes over the scrollbar, the selected font loses "hover" focus and the submenu disappears. This makes the submenu very difficult to hit (I think that you can move fast and skip over the scrollbar, but it's very difficult).

What should happen:

It's unclear what the right answer is here, but what is very clear is that browsers are massively inconsistent. Safari and Edge (and presumably Chrome) work fine because the submenu renders above the scrollbar. So it seems like Firefox is in the rough here and some investigation is justified.

I'll attach screenshots from Safari and Edge for reference.

This is what Edge (and probably Chrome) look like.

Safari is fine, though it has some unrelated issues.

A workaround is to enable "Always show scrollbars" option. (I have enabled it so initially I didn't see the issue).

I am totally unsure why the overlay scrollbar changes the submenu position.

CCing Emilio.

The page might be trying to calculate scrollbar width and adjust for it in it's placement of the submenus? Or perhaps the scrollbars would draw on top of the submenu before bug 1827337 was fixed and google was trying to move them over to avoid that?

FWIW, even without overlay scrollbars, and in Chrome, I find it hard to mouse over the submenu without it closing.

Marking S2 since I'd imagine this impacts a lot of users.

Two diagnostic notes:
(1) regarding this...
(In reply to Martin Thomson [:mt:] from comment #0)

When your mouse passes over the scrollbar, the selected font loses "hover" focus and the submenu disappears. This makes the submenu very difficult to hit (I think that you can move fast and skip over the scrollbar, but it's very difficult).

Interestingly, the menus in Google Docs' Menu-bar (File|Edit|View|Insert) don't seem as-bad. If you perform the STR with one of those menus, then the submenu doesn't disappear as easily (there's less of a "dead area" for whatever reason; the submenu disappears if you move your cursor quite slowly, but a regular-speed mouse-move can reach the submenu just fine). It looks visually the same, I think, so there might be some relevant difference between these two sets of menus that could be

(2) Comparing Firefox to Epiphany (WebKit) on Ubuntu -- both of which generally use overlay scrollbars on my machine -- it looks like Google Docs is forcing traditional/non-overlay scrollbars in these menus, using these styles:

::-webkit-scrollbar {
height: 16px;
overflow: visible;
width: 16px;
}

https://docs.google.com/static/document/client/css/3061990647-KixCss_ltr.css

If I uncheck those^ styles in devtools, then Epiphany hits the same issue as described in comment 0.

So what's happening here is that Google Docs is depending on those ::-webkit-scrollbar styles (and in particular, they're probably depending on them making the scrollbar subtract some width from the scrolled box's width, and the popup is probably styled to appear at the upper right corner of that scrolled box).

(I recall us supporting some minimal set of webkit scrollbar styles for compat, but apparently we don't support the relevant ones used here.)

So a rough diagnosis here:
(1) The submenus here are dynamically positioned, at the moment that they appear, using style="left: Npx" for some N that's calculated in JS.
(2) I suspect Google Docs is calculating this Npx such that it's (roughly) a point at the absolute right edge of the scrolled box in the top-level menu.
(3) With traditional (non-overlay) scrollbars, this point is to-the-left-of the scrollbar.
(4) But with overlay scrollbars, this point is underneath the scrollbar track (because the scrollbar doesn't occupy any space). This means there's some dead space that makes the submenu disappear, regardless of browser (at least: in WebKit and Gecko).
(5) So things work out fine if the user has traditional (non-overlay) scrollbars -- and Google Docs tries to force that, using ::-webkit-scrollbar styles from comment 6. And that does force traditional scrollbars in WebKit (and Chromium I assume), but it doesn't in Firefox.

Here's a reduced testcase. There's a red box that's indicating roughly where the submenu would be appearing.

With traditional scrollbars (that Google Docs is trying to force), that red box doesn't overlap anything and it can be hovered / moused into.

With overlay scrollbars (e.g. Firefox & WebKit-if-you-untick-the-webkit-scrollbar-styles-here), that red box gets covered up by the overlay scrollbar and can't be hovered/moused into.

[CC twisniewski as FYI for WebCompat team, since this is sorta WebCompat]

Google Docs could theoretically work around this (mostly) if they knew the width of the scrollbar, so that they could properly dodge the scrollbar in comment 7. That's not a standard web-exposed thing right now, though; that's tracked in https://github.com/w3c/csswg-drafts/issues/4691

Thanks, Dan. We'll at least try to get an intervention out in the 116 release cycle for Windows and Linux users, if we can't find the time to make a JS intervention which reliably detects when a scrollbar is present and adjusts the menu positions accordingly.

Doesn't this affect macOS too?

Actually I just tried force-enabling scrollbars on my macbook, and the menus overlap on top of the scrollbar, so I don't think so?

No, I was wrong. The "only when scrolling" overlay scrollbars are indeed broken. But I think we can just nudge all of the submenus with some CSS regardless of scrollbars, so we should be fine.

Yes, this CSS seems to do the trick:

[class="goog-menu goog-menu-vertical"], /* font family sub-menus */
.goog-menu.apps-menu-hide-mnemonics { /* font style sub-menus */
    margin-inline-start: -20px;
}

It's unclear if this misses any edge cases or sub-menus that I don't see, but it doesn't strike me as likely to break anything more than the current status quo, so it seems worth trying.

Thank you Daniel for diagnosing!

Reclassifying as WebCompat since this is a case where the site is relying on non-standard ::-webkit-scrollbar, and we're hoping to ship an intervention to work around that dependency.