1836872 - Google Docs Font submenus are inaccessible, due to overlay scrollbar appearing & overlapping the hover target (when browser/system is configured to use overlay scrollbars)

Status: ASSIGNED

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

Description

[Martin Thomson [:mt:]]

Attachment: image.png

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.

Comment 1

[Martin Thomson [:mt:]]

Attachment: edge.png

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

Comment 2

[Martin Thomson [:mt:]]

Attachment: safari.png

Safari is fine, though it has some unrelated issues.

Comment 3

[Hiroyuki Ikezoe (:hiro)]

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.

Comment 4

[Timothy Nikkel (:tnikkel)]

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.

Comment 5

[Dan Robertson (:dlrobertson)]

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

Comment 6

[Daniel Holbert [:dholbert]]

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.)

Comment 7

[Daniel Holbert [:dholbert]]

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.

Comment 8

[Daniel Holbert [:dholbert]]

Attachment: testcase 1 (load this in a browser *configured to use overlay scrollbars*)

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.

Comment 9

[Daniel Holbert [:dholbert]]

[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

Comment 10

[Thomas Wisniewski [:twisniewski]]

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.

Comment 11

[Emilio Cobos Álvarez (:emilio)]

Doesn't this affect macOS too?

Comment 12

[Thomas Wisniewski [:twisniewski]]

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?

Comment 13

[Thomas Wisniewski [:twisniewski]]

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.

Comment 14

[Thomas Wisniewski [:twisniewski]]

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.

Comment 15

[Botond Ballo [:botond]]

Thank you Daniel for diagnosing!

Comment 16

[Daniel Holbert [:dholbert]]

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.

Comment 17

[Martin Thomson [:mt:]]

I don't know if this is the same problem, but I am now unable to select fonts that have a submenu, unless they are toward the top of the list. The menu scrolls to the top as soon as the mouse hovers over a font, which makes it virtually impossible to use. Do we have contacts at Google Docs we can point to this bug?

Comment 18

[Timothy Nikkel (:tnikkel)]

That sounds maybe like bug 1853079?

Comment 19

[Raul Bucata]

Verified this issue and could not reproduce it on Firefox versions 122 and 124. Tom, there is an intervention is place, but I was unable to reproduce with the interventions set to TRUE or FALSE. Should we keep this open, if others can confirm this?

Martin, does the reported issue still reproduces for you?

Tested with:

Browser / Version: Firefox Release 122.0.1 (64-bit)/ Firefox Nightly 124.0a1 (2024-02-17) (64-bit) / Chrome Version 121.0.6167.161 (Official Build) (64-bit)
Operating System: Windows 10 PRO x64

Comment 20

[Martin Thomson [:mt:]]

I don't see any improvement in Nightly 2024-02-11, 2024-02-15, or 2024-02-19 (which is 125). I wasn't able to find any active intervention for the site.

Comment 21

[Daniel Holbert [:dholbert]]

(In reply to Raul Bucata from comment #19)

I was unable to reproduce
[...]
Operating System: Windows 10 PRO x64

Given that you're on Windows 10, I suspect you've got "traditional" non-overlay scrollbars ("Always show scrollbars") -- that's the default in Windows 10. And per comment 3, that configuration works around this bug. So I don't think anything has changed here; Raul was likely just confirming comment 3.

To actually repro/test this bug, you need to be using overlay scrollbars. I don't recall how to activate that configuration on Windows 10 (I don't have Win10 handy), but it's the default configuration in Win11 and on macOS (configurable in system settings on both), and it's configurable in Firefox preferences on Linux.

Comment 22

[Raul Bucata]

Indeed Daniel, with overlay scrollbars in place, the issue reproduces on Mac and Windows 11. Thanks for that.

Comment 23

[Masatoshi Kimura [:emk]]

For the record, set widget.non-native-theme.scrollbar.style to 5 to force enable Windows 11 style scrollbars on Windows 10.

Comment 25

[Thomas Wisniewski [:twisniewski]]

Attachment: Bug 1836872 - add a CSS intervention to keep Google Docs font sub-menu popups from vanishing while trying to mouse over to them; r=ksenia

Comment 26

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/6998fe0c8ee1
add a CSS intervention to keep Google Docs font sub-menu popups from vanishing while trying to mouse over to them; r=ksenia,webcompat-reviewers

Comment 27

[Serban Stanca [:SerbanS]]

https://hg.mozilla.org/mozilla-central/rev/6998fe0c8ee1