User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:29.0) Gecko/20100101 Firefox/29.0 (Beta/Release) Build ID: 20140327140727 Steps to reproduce: OSX 10.8.5 Firefox 28 + Trunk 31 1.) Enable 'two finger horizontal swipe' in OSX system preferences 2.) Open a long page with a vertical scrollbar 3.) Scroll horizontally to the right (although there is no horizontal scrollbar) 4.) And then immediately scroll vertically Actual results: I can't scroll vertically. It is blocked for a second. When I repead the vertical scrolling gesture, then scrolling works. Expected results: Vertically scrolling should work immediately. If you need more information, please let me know.
Confirmed in OSX 10.8.5 on Firefox 28 and in Nightly. There are a few other Mac two-finger scrolling bugs that may be related issues; they're scattered around in different bugzilla components and it will take a little work to sort through them.
Not an APZC bug since APZC isn't enabled on Mac OS X. Olli, do you know what the right component for this is?
Sounds like wheel transaction handling. We don't immediately start to scroll something else when mouse is over it - if there is ongoing wheel transaction. Sounds like we could use a tweak somewhere. I can't reproduce on linux.
Component: Panning and Zooming → Event Handling
Do you reproduce with this? This testcase scrolls the contents without wheel event transaction. I.e., if you can reproduce this bug with this testcase, this bug must be cocoa widget's.
(In reply to Masayuki Nakano (:masayuki) (Mozilla Japan) from comment #4) > Created attachment 8401103 [details] > testcase > > Do you reproduce with this? This testcase scrolls the contents without wheel > event transaction. I.e., if you can reproduce this bug with this testcase, > this bug must be cocoa widget's. @Masayuki Nakano: Thanks for testcase example. Unfortunately I can reproduce the bug with the testcase :-( This seems to be only a problem, when the swipe-feature is enabled in the OS Trackpad preferences.
Dear Core::Cocoa:Widget, maybe you will be the final home for this lonely bug. :)
Component: Event Handling → Widget: Cocoa
We are seeing quite a few reports of this issue in Input and on the SUMO forums. Substantial increase after the 29 launch. I've got emails out to all the users that provided us contact information. No one on my team can repro this in house. If I do get some users willing to work 1 on 1, who should I put them in touch with? CC'ing Sylvestre just so it is on his radar.
Just tried to reproduce this again and I can finally reproduce the problem! Just to be clear: I'm able to reproduce the originally reported issue here, i.e. vertical scrolling starts working again after ~1 second. Matt, is that what's being reported in Input and on SUMO?
The reports we are seeing are vague which is why we are reaching out to users individually. Here's what know: 1. Seems to be OSX 10.9 only 2. At some point (steps vary) two finger scrolling stops working 3. Some reports indicate mouse scrolling stops working as well 4. Most users report that restarting Firefox is the ONLY way to restore functionality 5. Scroll bars seem to work throughout the process I'm hoping to hear back from some of the users today.
Thanks, Matt! I think sending people to this bug here would be a good place to start gathering info. Please note that if scrolling stops working completely, it may bug 927702, which is currently believed to be an Apple bug (since Safari is also affected). If someone is able to reproduce consistently, we might be able to find a commit on our side that makes this bug occur more frequently. If so, let's discuss in bug 927702.
Hey Stephen. I think you are right that this is probably 927702 related. Reports are definitely that scrolling stops working completely. We'll direct any additional data there. Thanks.
This essentially reverts this section of nsChildView.mm to the way it was before adding code for the vertical page bounce. I suspect that once we enable vertical page bounces we will need to revisit this. We may have to be more granular and only do what this code was trying to do when we're dealing with vertical overscrolls and leave the logic for horizontal swipes the way it is. There is quite a bit of work left to do for horizontal swipe animations. I suspect that we will add page bounce only after we have horizontal swipe animations, so it seems like a long way out. I think we should just revert this until we get to it.
Assignee: nobody → spohl.mozilla.bugs
Status: NEW → ASSIGNED
Attachment #8418942 - Flags: review?(smichaud)
Forgot to mention that page bounce was added in bug 673875, and the changeset was http://hg.mozilla.org/mozilla-central/rev/b784c6dafa7d
Comment on attachment 8418942 [details] [diff] [review] Patch Sounds like this is worth a try. Confusion with bug 927702, though, will make it difficult to tell whether or not this patch has done any good. (Bug 927702 is definitely at least partly an Apple bug.)
Attachment #8418942 - Flags: review?(smichaud) → review+
(In reply to Steven Michaud from comment #14) > Confusion with bug 927702, though, will make it difficult to tell whether or > not this patch has done any good. (Bug 927702 is definitely at least partly > an Apple bug.) I agree that this should not be taken as an attempt at fixing bug 927702, i.e. the permanent inability of scrolling or swiping. It will definitely do good though by fixing the bug that was originally reported here, i.e. the ~1 second delay before vertical scrolls start working again (see description).
Hi Stephen Pohl [:spohl], I am the reporter of this issue. Thanks for looking into it! But unfortunately your patch only fixed the bug partially: Now, the ~1 second delay scrolling issue is fixed, but inertia scrolling doesn't work, when you do a vertical swipe after the horizontal swipe. Steps to reproduce: 1.) Scroll horizontally to the right (although there is no horizontal scrollbar) 2.) And then immediately do a swipe down and lift your fingers for inertia scrolling. Actual result: Scrolling stopps immediately, after you lift your fingers from the trackpad. Expected result: The page should scroll further, although I lift my fingers from the Trackpad. Should I open a new report for this issue? Tested with 32.0a1 (2014-05-09) on OSX 10.8.5. Thanks in advance!
Hi Mehmet, yes, please open a separate bug for this. Please also mention whether or not inertia scrolling remains broken for you, or if it starts working again (and after how long). These two issues might not be directly related. Your info will help us figure that out. Thanks!
(In reply to Stephen Pohl [:spohl] from comment #19) > Hi Mehmet, yes, please open a separate bug for this. Please also mention > whether or not inertia scrolling remains broken for you, or if it starts > working again (and after how long). These two issues might not be directly > related. Your info will help us figure that out. Thanks! Sorry, I didn't mention it: Inertia scrolling works immediately again, when I do the next (second) swipe down. I Filed Bug 1008204. Many thanks!
Even though this is only a partial fix, let's get more users on it - please nominate for uplift so we can get it landed in this Thursday's Beta.
Comment on attachment 8418942 [details] [diff] [review] Patch [Approval Request Comment] Bug caused by (feature/regressing bug #): Bug 673875 User impact if declined: After a horizontal swipe, vertical scrolling is blocked for ~1 second. Testing completed (on m-c, etc.): Has been on m-c for a few days. Risk to taking this patch (and alternatives if risky): Very small. This patch is essentially reverting a section of code to the state that we used to ship before bug 673875 landed. Bug 673875 remains turned off, so there is no immediate impact on that feature either. String or IDL/UUID changes made by this patch: none
Mehmet Sahin, I don't have a trackpad available at the moment and it seems that my magic mouse (which is also gesture-enabled) didn't replicate this issue in the first place. Could you please verify this fix on your trackpad with the latest Beta, Aurora and Nightly builds?
Verified as fixed in FF Beta 6, FF Aurora 31.0a2 (2014-05-23) and FF Nightly 32.0a1 (2014-05-23). (Note: There is a further issue (Bug 1008204), which I realized after this one was fixed.)
Thanks, Mehmet Sahin! Marking as verified based on comment 26.
You need to log in before you can comment on or make changes to this bug.