Closed Bug 1390580 Opened 7 years ago Closed 6 years ago

Unable to scroll Google Docs comment discussions with trackpad

Categories

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

defect

Tracking

(platform-rel ?)

RESOLVED FIXED
Tracking Status
platform-rel --- ?

People

(Reporter: Atoll, Unassigned)

References

Details

(Whiteboard: [sitewait] [priority-critical][platform-rel-Google])

While trying to operate a Google Doc (w/ Mozilla SSO, in case it matters), I found that when I put the pointer over a long comments conversation in a doc and scroll down with the trackpad, the scroll event is ignored.

To reproduce this, create a small Google Sheet (delete all but 3 columns and 10 rows), add a Comment to any cell, and then reply to the comment several times. It will eventually be so long that a scrollbar is introduced.

In Firefox, attempting to scroll that conversation is impossible by any means other than clicking and dragging the scroller.

In Chrome, scrolling the conversation simply requires moving the pointer over the conversation and then scrolling as normal with the trackpad.

Firefox 57.0a1 (2017-08-15)
Karl, can you doublecheck if this is a web compat or a gecko issue? Maybe you know if this is already on file somewhere?

Richard, I assume this is on OS X?
Component: General → Untriaged
Flags: needinfo?(kdubost)
Product: Firefox → Core
Yes, 10.12.6 (16G29) - release.
Simpler Steps to reproduce:

1. Open a new sheet.
2. Insert a very long new comment: 
   Lorem ipsum dolor sit amet, consectetur adipisicing elit, sed do eiusmod
tempor incididunt ut labore et dolore magna aliqua. Ut enim ad minim veniam,
quis nostrud exercitation ullamco laboris nisi ut aliquip ex ea commodo
consequat. Duis aute irure dolor in reprehenderit in voluptate velit esse
cillum dolore eu fugiat nulla pariatur. Excepteur sint occaecat cupidatat non
proident, sunt in culpa qui officia deserunt mollit anim id est laborum.
3. Impossible to scroll that comment.


I do not remember any issues related to that, but let's put that on the priority train for diagnosis.
Flags: needinfo?(kdubost)
Thomas, 
Could you check this? 

I see two nested divs with events set on the comment box.
Component: Untriaged → Desktop
Flags: needinfo?(wisniewskit)
Product: Core → Tech Evangelism
Whiteboard: [neesdiagnosis][priority-critical]
On my OSX 10.12 MacBook, I can't reproduce with Karl's STR. It works the same in Chrome and Firefox; it always shows the full comment when I double-click it, and if I don't (and there is content in the cell next to it, obscuring its own content), then neither browser can scroll around on it without first double-clicking it as though to edit its contents. If I shrink the browser window to a very small size, both browsers cannot scroll it (and they both show a pop up that the window is too tiny for the sheet to work properly). Also, if I simply paste in the comment without double-clicking on a cell first, Sheets will split the comment into multiple cells, one above the other, line by line. But things otherwise work the same way.

I *can* however reproduce with the original STR. I can drag the scrollbar manually, but can't use the "scroll wheel" (be it a trackpad on my MacBook, or a physical mouse scrollwheel on my Linux dev box). It does work in Chrome, however, so I'll investigate based on those STR.
Flags: needinfo?(wisniewskit)
I'm not sure what to recommend here. The minified code is just a bit too terse to make sense of what they're trying to do or why.

It looks like they're listening for wheel events, which get preventDefault()ed in the p.s_b function in script [1]. This seems to be because they want to manually handle the scrolling of the element in the same function.

However, p.s_b seems to be incorrectly changing the wheel deltas {x:0,y:-3} to {x:0,y:-0} and then sending those to (what seems to be) the actual function to scroll the element, y0a. But even when I hack y0a to force-try to scroll by bypassing its guards, it doesn't accept the value {x:0,y:-3} (I get a page error) and the value {x:0,y:3} doesn't end up scrolling anything.

I also note that if I comment out the preventDefault in p.s_b, then Firefox does scroll. Indeed Chrome gets a different script version [2] which doesn't preventDefault either (the wheel listener doesn't appear to be triggered at all in that version). But I can't UA spoof to Chrome, or I get a vague page error popup. So I'm at a loss.


[1] https://docs.google.com/static/spreadsheets2/client/js/295605113-ritz_waffle_integrated_i18n_core.js
[2] https://docs.google.com/static/spreadsheets2/client/js/3376631534-ritz_waffle_i18n_core.js
Okay, so the JavaScript is broken, not our browser, and that they're serving bad JS means of course it's broken. Someone suggests "webcompat.com", where I'll take this bug, but I think other than that this isn't a Firefox bug, it's a "Google serves broken JS to Firefox" bug, and that seems not very appropriate for Core (unless y'all think it is).
Google was contacted today.
Whiteboard: [neesdiagnosis][priority-critical] → [sitewait] [priority-critical]
See also some of the findings by Thomas in https://webcompat.com/issues/8012#issuecomment-323839251
about deltaMode
from Google

> Bug resolved internally. Will ping this thread when rolled out to all users.

\o/
platform-rel: --- → ?
Whiteboard: [sitewait] [priority-critical] → [sitewait] [priority-critical][platform-rel-Google]
Richard, can you confirm that this is indeed fixed?
Flags: needinfo?(rsoderberg)
Priority: -- → P1
I *believe* it's fixed. I followed :karlcow's STR from comment 3 and I can now scroll when there are several comments!
Flags: needinfo?(rsoderberg)
Sweet, thanks!
Status: NEW → RESOLVED
Closed: 6 years ago
Resolution: --- → FIXED
Product: Tech Evangelism → Web Compatibility
You need to log in before you can comment on or make changes to this bug.