Closed
Bug 1267445
Opened 9 years ago
Closed 8 years ago
Sideways two-finger scrolling in a split google sheets is twitchy.
Categories
(Web Compatibility :: Site Reports, defect, P1)
Tracking
(platform-rel +)
RESOLVED
FIXED
Tracking | Status | |
---|---|---|
platform-rel | --- | + |
People
(Reporter: jst, Unassigned)
References
()
Details
(Whiteboard: [sitewait] [js] [country-all] tpi:+ [platform-rel-Google][platform-rel-GoogleSuite][platform-rel-GoogleSheets])
If you split a Google spreadsheet horizontally then the sideways scrolling of the right side of the split is very unpredictable and very twitchy in Firefox on at OS X (though not on Linux).
For those who do a ton of work in Google Sheets this is very annoying and causes users to switch to another browser... See linked spreadsheet for an example, try to scroll the right side of the spreadsheet sideways with two finger scrolling on a track pad.
https://docs.google.com/spreadsheets/d/1mzi9wk0VtVr8kUEF0pxmotY8fnQB5-TGWzHRgMA3ZWU/edit
Comment 1•9 years ago
|
||
At first I agreed with you... Then I looked into my trackpad preferences (additional gestures) and noticed that the first line (sorry my computer is in french, so it may not be a correct translation):
'swipe between pages' was selected as '2 finger scroll' (1st item) and if I understand correctly this feature, it's for going back and forth in the browsing page history. If I changed it to '3 fingers swipe' (2nd or 3rd item on the list), I was able to scroll horizontally in your google spreadsheet.
However, I tested the same link in safari with the '2 finger scroll' selected (as it is the default setting) and there is no problem, the horizontal scroll is perfect (and erratic on Nightly with these same settings).
But if I open a large image (wider than my window) and zoom it to actual size, I can scroll horizontally and vertically without a problem on Firefox (and without going one page back).
So clearly there is a problem on how Firefox handles the split google spreadsheet (not like the non spreadsheet)
Confirmed on Nightly 20160503030421 on mac OSX
![]() |
||
Comment 2•9 years ago
|
||
jst, are you still seeing this? Testing in Safari and firefox 49, two finger scroll moves from cell to cell, which ais expected.
Flags: needinfo?(jst)
Reporter | ||
Comment 3•9 years ago
|
||
I am, or more specifically mrbkap was as he helped me test this. Something's still not right here.
Flags: needinfo?(jst)
![]() |
||
Comment 4•9 years ago
|
||
Note this is related to horizontal scroll of the split panel.
Priority: -- → P2
Whiteboard: tpi:+
![]() |
||
Updated•9 years ago
|
Priority: P2 → P1
![]() |
||
Comment 5•9 years ago
|
||
From Kats:
It looks like Google Sheets uses a canvas and intercepts
DOMMouseScroll events to implement their own scrolling. As long as we
are dispatching those events properly it should work fine, but
horizontal swiping is impacted by the back/forward detection as well.
That might be impacting the events we're sending, I'm not sure. If you
want me to investigate more I can do that, but it'll delay touch
support on Windows which is what I'm working on now.
Comment 6•9 years ago
|
||
So we do dispatch pixel level wheel events on OSX, and the legacy
MozMousePixelScroll and DOMMouseScroll. If the page is handling only DOMMouseScroll, I assume it might
miss some information.
It should use wheel events which are implemented in all the browsers.
Comment 7•9 years ago
|
||
This looks like an evang issue to me.
Comment 8•9 years ago
|
||
Is the behavior the same if chrome UA string is used?
![]() |
||
Comment 9•9 years ago
|
||
STR:
1) open test case
https://docs.google.com/spreadsheets/d/1mzi9wk0VtVr8kUEF0pxmotY8fnQB5-TGWzHRgMA3ZWU/edit
2) click on the right side pane
3) drag two fingers back and forth over the mac track pad horizontally
result: nothing
expected: the right hand spread sheet pane should scroll horizontally
4) drag two fingers vertically across the track pad to start a vertical scroll, then continue horizontally
result: spreadsheet scrolls vertically then horizontally
expected: same
It seem we don't do a good job of detecting the start of a horizontal drag.
Comment 10•9 years ago
|
||
Or more likely the web page isn't handling the event for that scroll.
Updated•9 years ago
|
platform-rel: --- → ?
Whiteboard: tpi:+ → tpi:+ [platform-rel-Google][platform-rel-GoogleDocs]
Updated•9 years ago
|
platform-rel: ? → +
Comment 11•9 years ago
|
||
Karl, given comment #6, can we bring this up with Google?
Component: Widget: Cocoa → Desktop
Flags: needinfo?(kdubost)
Product: Core → Tech Evangelism
Reporter | ||
Comment 12•9 years ago
|
||
Olli already raised this with Google last week. IIRC we're still waiting on a response.
![]() |
||
Comment 13•9 years ago
|
||
Yup confirmed that the contact has been started. Thanks Olli.
Message-ID: <579A7904.60803@mozilla.com>
Date: Fri, 29 Jul 2016 00:28:36 +0300
And Google has routed to someone who might be able to help.
Switching to sitewait.
Flags: needinfo?(kdubost)
Whiteboard: tpi:+ [platform-rel-Google][platform-rel-GoogleDocs] → [sitewait] [js] [country-all] tpi:+ [platform-rel-Google][platform-rel-GoogleDocs]
Comment 14•8 years ago
|
||
I've been looking into this. I believe there are two issues:
1. It is impossible to scroll horizontally, unless a vertical scroll is initiated first.
2. When scrolling horizontally, we skip over columns when scrolling right but skip over different columns when scrolling left, which makes it seem erratic (or "twitchy", as stated in the bug title).
I've focused on 1 first since it appears to be the greater problem of the two.
It turns out that we fail to scroll horizontally because we believe that we're initiating a horizontal swipe. While tracking horizontal swipes we're not sending DOMMouseScroll events. I find it suspect that scrollTarget is null in EventStateManager::PostHandleEvent[1] when we clearly seem to have a scroll target in Google Docs. If scrollTarget was non-null, we wouldn't set mViewPortIsOverscrolled to true for the event[2] and we would not track scroll events as swipe[3].
I've confirmed that if we no longer track these horizontal scroll events as swipe, DOMMouseScroll events are sent successfully and we can properly initiate horizontal scrolls in Google Docs. This still leaves problem 2 though.
[1] https://hg.mozilla.org/mozilla-central/annotate/26e22af660e543ebb69930f082188b69ec756185/dom/events/EventStateManager.cpp#l3223
[2] https://hg.mozilla.org/mozilla-central/annotate/26e22af660e543ebb69930f082188b69ec756185/dom/events/EventStateManager.cpp#l3224
[3] https://hg.mozilla.org/mozilla-central/annotate/26e22af660e543ebb69930f082188b69ec756185/widget/cocoa/nsChildView.mm#l2937
Comment 15•8 years ago
|
||
Don't forget to test MozMousePixelScroll handling. That could lead to (2) (which I thought this bug is about).
Comment 16•8 years ago
|
||
(In reply to Olli Pettay [:smaug] from comment #15)
> Don't forget to test MozMousePixelScroll handling. That could lead to (2)
> (which I thought this bug is about).
For each initiated horizontal scroll we send one MozMousePixelScroll event with an mDelta of 1. All subsequent obj-c scroll events are then tracked as swipe and we don't send any more MozMousePixelScroll events until a new horizontal swipe is initiated. We don't send a DOMMouseScroll event along with this first MozMousePixelScroll, since the mDelta for DOMMouseScroll is 0.
If we initiate a vertical scroll first and immediately go to a horizontal scroll without releasing the touchpad, both DOMMouseScroll and MozMousePixelScroll events are sent continuously, since we're not tracking the horizontal scroll as swipe.
From what I can tell based on the loaded .js files[1][2][3][4][5], Google Docs only seems to handle DOMMouseScroll and mousewheel events.
So, comment 6 still applies: If Google Docs handled wheel events, it would seem that this would fix issue 2 from comment 14.
We should still do something about issue 1 in comment 14. Detecting that we have a scroll target on the page seems like the right fix, but at this point it isn't clear to me why this isn't already the case.
[1] https://docs.google.com/static/spreadsheets2/client/js/1101830378-ritz_waffle_i18n_core.js
[2] https://docs.google.com/static/spreadsheets2/client/js/2654039544-ritz_waffle_i18n_viewer.js
[3] https://docs.google.com/static/spreadsheets2/client/js/3599812221-ritz_waffle_i18n_gvizcharts.js
[4] https://docs.google.com/static/spreadsheets2/client/js/3575830417-ritz_waffle_i18n_docos.js
[5] https://docs.google.com/static/spreadsheets2/c76dd15d6a/ritz/6C357BC239E040DCE0E28AAB9D96A9E6.cache.js
Comment 17•8 years ago
|
||
Unfortunately, my attempts at figuring out why we have a null scrollTarget in EventStateManager::PostHandleEvent[1] (see comment 14) have been fruitless so far. :smaug, is this something straightforward for you to figure out? Or do you know who could help here? Thanks!
[1] https://hg.mozilla.org/mozilla-central/annotate/26e22af660e543ebb69930f082188b69ec756185/dom/events/EventStateManager.cpp#l3223
Flags: needinfo?(bugs)
Updated•8 years ago
|
Whiteboard: [sitewait] [js] [country-all] tpi:+ [platform-rel-Google][platform-rel-GoogleDocs] → [sitewait] [js] [country-all] tpi:+ [platform-rel-Google][platform-rel-GoogleDocs] [platform-rel-GoogleSheets]
Updated•8 years ago
|
Whiteboard: [sitewait] [js] [country-all] tpi:+ [platform-rel-Google][platform-rel-GoogleDocs] [platform-rel-GoogleSheets] → [sitewait] [js] [country-all] tpi:+ [platform-rel-Google][platform-rel-GoogleSuite][platform-rel-GoogleSheets]
Updated•8 years ago
|
Rank: 6
Comment 18•8 years ago
|
||
I have filed bug 1320421 to deal with the first issue described in comment 14. This bug should track the tech evangelism issue of having Google Docs switch to the new wheel events (second issue described in comment 14 & comment 16).
Clearing n-i as there is a patch with feedback request for the first issue from comment 14 in bug 1320421.
Flags: needinfo?(bugs)
(In reply to Stephen A Pohl [:spohl] from comment #18)
> I have filed bug 1320421 to deal with the first issue described in comment
> 14. This bug should track the tech evangelism issue of having Google Docs
> switch to the new wheel events (second issue described in comment 14 &
> comment 16).
+:miketaylr - for the TE bit
+:ssaviano - for the Google Suite Sheets team supporting new wheel events comments
Flags: needinfo?(ssaviano)
Flags: needinfo?(miket)
Comment 20•8 years ago
|
||
Focusing our efforts first on https://bugzilla.mozilla.org/show_bug.cgi?id=1205573
Will evaluate this issue after that is resolved. Thanks for sharing!
Comment 21•8 years ago
|
||
We did reach out to Google about this (see Comment #13) 4 months ago, but it seems like nothing happened. I re-pinged the thread.
Flags: needinfo?(miket)
Comment 22•8 years ago
|
||
(and to follow up, Google is going to work on Bug 1205573 before getting to this -- thanks Steven!)
Comment 23•8 years ago
|
||
FYI - I've filed bug # 33172560 to track this issue on the Google side.
Comment 24•8 years ago
|
||
Bug 1320421 comment 2 indicates DOMMouseScroll is no longer used in Google Sheets. Steven, can you confirm some changes were made in Google Docs? TIA :)
Comment 25•8 years ago
|
||
Yes, we have been making changes as recommended. I believe another change or so is still slated to rollout this week for better mouse wheel support. We still need to verify this specific issue though. Myself or Josh will report back.
Comment 26•8 years ago
|
||
Still waiting here on confirmation from specific eng that all cases are handled. Didn't loose track.
Flags: needinfo?(ssaviano)
Comment 27•8 years ago
|
||
Confirmed that this is fixed on our end. Andrew, I'm not sure I can mark this as fixed (doesn't seem like it), but feel free to verify and close out.
Flags: needinfo?(overholt)
Comment 28•8 years ago
|
||
I can confirm this is fixed and working now -- thanks!
Status: NEW → RESOLVED
Closed: 8 years ago
Flags: needinfo?(overholt)
Resolution: --- → FIXED
Reporter | ||
Comment 29•8 years ago
|
||
(In reply to Steven Saviano from comment #27)
> Confirmed that this is fixed on our end. Andrew, I'm not sure I can mark
> this as fixed (doesn't seem like it), but feel free to verify and close out.
Thanks Steven! I just gave you super powers in bugzilla so you can edit bugs going forward, use them carefully :)
Comment 30•8 years ago
|
||
Thanks! Will only use as appropriate on the Google-specific bugs.
Assignee | ||
Updated•6 years ago
|
Product: Tech Evangelism → Web Compatibility
You need to log in
before you can comment on or make changes to this bug.
Description
•