1882226 - Google Docs fonts menu has a huge scroll-position-change (jumping upwards in the font list), if you scroll down and then move cursor around to choose a font

Status: RESOLVED DUPLICATE of bug 1853079

(Core :: Layout: Scrolling and Overflow, defect)

Description

[Aaron Benson]

Observed on macOS

STR:

• Open a google doc (new or existing)
• Type some text in the doc, or select existing text
• Click the fonts menu and then scroll to the bottom of the list
• Move mouse cursor to make a font selection

At this point, the font list appears to "jump" back to the top, making it impossible for me to select a font lower down on the list. It is also difficult to navigate the flyout menus in the font list because as the mouse cursor traverses over the scrollbar area, the flyout disappears.

Comment 1

[Mike Conca [:mconca]]

Attachment: No font scroll

Video from Aaron Benson that shows the issue on macOS. I have been able t reproduce this on Windows.

Comment 2

[Mike Conca [:mconca]]

Moving to Layout for first triage

Comment 3

[Daniel Holbert [:dholbert]]

It is also difficult to navigate the flyout menus in the font list because as the mouse cursor traverses over the scrollbar area, the flyout disappears.

This part is bug 1836872.

I don't think the "Jump back to the top" part is covered by that bug, though.

Comment 4

[Daniel Holbert [:dholbert]]

I can reproduce the jump - it seems to happen if I move my cursor to/from a font name that triggers a flyout menu.

Comment 5

[Frank Griffith Jr]

Have been able to reproduce in FF x124 and Win 11

Comment 6

[Daniel Holbert [:dholbert]]

Here's a performance profile where the "jump" happens: https://share.firefox.dev/3OUHh8w

Comment 7

[Daniel Holbert [:dholbert]]

I haven't been able to reproduce in Chrome or Safari, so this seems to be Firefox-specific. (Minor caveat: I can reproduce a very-small single-menu-item-height "jump" if I hover the very top of the font list, after having scrolled to the end; because, hovering that top list-entry causes the list to scroll to show that entry. That seems to be by-design and much less severe than what's being discussed here.)

In Firefox Nightlies: I can reproduce the large "jump" at least as far back as Nightly 2022-01-01 (v97.0a1), so this is not a recent regression on our side. If this issue only just started happening, then it wasn't due to a change on our side. (Still might be arguably our bug, but a longstanding bug that [maybe] Google Docs just started tripping over in a recent deployment.)

I can reproduce the jump even if I spoof a Chrome UA string, too, so there's no UA-sniffing involved in triggering the bad condition.

Comment 8

[Dan Robertson (:dlrobertson)]

I just did a bit of debugging. I thought this might have been similar or made worse by our recent changes to make Element.focus() center an element. After further investigation, this does not appear to be the case. We do not seem to trigger the scroll do to the logic in ComputeNeedToScroll. The ScrollOperationParams.mTriggeredByScript flag is set to ScrollTriggeredByScript::Yes in recent debugging sessions, which AFAIK indicates there is an explicit scroll operation that is triggering it. This doesn't necessarily mean there is no bug in our code, but I think this indicates this isn't a bug due to our recent changes to Element.focus().

I'll continue to attempt to debug this a bit more.

Comment 9

[Dan Robertson (:dlrobertson)]

I think this is a duplicate of Bug 1589505

Comment 10

[BugBot [:suhaib / :marco/ :calixte]]

The severity field is not set for this bug.
:hiro, could you have a look please?

For more information, please visit BugBot documentation.

Comment 11

[Hiroyuki Ikezoe (:hiro)]

I would say this is a duplicate of bug 1836872.

Comment 12

[Hiroyuki Ikezoe (:hiro)]

Wrong bug number. :/