Closed Bug 1221913 Opened 4 years ago Closed 4 years ago

[e10s] Horizontal Scroll not working correctly


(Core :: Widget: Cocoa, defect)

44 Branch
Not set



Tracking Status
e10s m8+ ---
firefox45 --- fixed


(Reporter: johan, Assigned: mstange)



(2 files)

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.11; rv:44.0) Gecko/20100101 Firefox/44.0
Build ID: 20151104004053

Steps to reproduce:

Scroll horizontally in a div with overflow-x: scroll with a Magic Mouse or a Magic Trackpad on OS X 10.11.1.

Actual results:

The div always scrolls 1 px.

Expected results:

The div should scroll corresponding to the input of the mouse like it did in the 43 Branch.
Unfortunately I'm not able to reproduce this on other machines than my own. Is there some info that would be helpful about my specific system?
Please check if the issue occurs using Firefox in safe mode (with your addons disabled):

And on a new, empty profile:

Moreover, check in the system preferences if your touchpad settings are still enabled.
Flags: needinfo?(johan)
Component: Untriaged → Event Handling
Product: Firefox → Core
Yes, the bug occurs even in safe mode and with an empty profile.

However, if I start it in a non-e10 window it works as it should. So it seems to be associated with multi-process windows.
Flags: needinfo?(johan)
Summary: Horizontal Scroll not working correctly → [e10s] Horizontal Scroll not working correctly
In a clean profile, can you go to about:config, set the layers.async-pan-zoom.enabled pref to false, restart the browser, and see if it still happens (in an e10s window)? That will help narrow it down. Thanks!
The default value for layers.async-pan-zoom.enabled is false. If I use the default value, it doesn't work. If I change it to true the scrolling starts working as expected.
Thanks for checking! This sounds like an e10s bug then.
tracking-e10s: --- → ?
Assignee: nobody → gwright
Kats, what's the likelihood you think that we'll be able to ship APZC with 45?
It's hard to say, but at this point the work items we have left don't seem like they'll fit in the time left we have for 45, specially given Mozlando eats up a week.
Bug 1221913 - Make swiping work correctly in e10s mode even if APZ is off. r?kats
Attachment #8690925 - Flags: review?(bugmail.mozilla)
Attachment #8690925 - Flags: review?(bugmail.mozilla) → review+
Comment on attachment 8690925 [details]
MozReview Request: Bug 1221913 - Make swiping work correctly in e10s mode even if APZ is off. r?kats

Seems like a straightforward enough fix, thanks!

::: dom/ipc/TabParent.cpp:2699
(Diff revision 1)
> +  // Do this even if APZ is off.

append "since we need it for swipe gesture support on OS X without APZ."
Thinking about it more, the above patch might have nonintuitive behaviour on non-OS X widgets. If we call InputAPZContext::SetRoutedToChildProcess without having an InputAPZContext instance on the stack somewhere, it sets sRoutedToChildProcess to true globally, and that will never get set back to false. In theory it shouldn't be a problem because nobody can read that value without having an InputAPZContext instance, but it makes me a little uneasy. Not sure if there's a good way to avoid it though.
(In reply to Kartikaya Gupta ( from comment #11)
> In theory it shouldn't be a problem because nobody can read that
> value without having an InputAPZContext instance

Right, I don't think it's worth worrying about. But good catch.

I did a bit more testing and realized that I wasn't setting mCurrentPanGestureBelongsToSwipe to true in the case where the event was sent to the content process. So I've moved that to the end of TrackScrollEventAsSwipe.
Assignee: gwright → mstange
Component: Event Handling → Widget: Cocoa
Ever confirmed: true
OS: Unspecified → Mac OS X
Hardware: Unspecified → All
Closed: 4 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla45
You need to log in before you can comment on or make changes to this bug.