Created attachment 639929 [details]
Unscrollable dropdown (Firefox)
1) Open Firefox.
2) Open the URL bar and go to news.google.com.
2a) If you are served the mobile site, scroll to the bottom and select "Classic" to get the desktop site.
3) Select the "U.S. edition" dropdown under the search bar (the dropdown text might vary based upon your location).
4) Attempt to scroll the dropdown.
Expected: The dropdown scrolls.
Actual: The dropdown is unscrollable and the entire page moves instead.
Both dropdowns on the page do not work.
The content appears to be div based, using custom css - a "goog-menu".
This is problematic on tablet devices which are served the desktop site by default.
Stock browser and Chrome are also unable to scroll. Chrome (phone) displays a improperly placed scrollbar but does not scroll. Tablet versions of both browsers expand the dropdown to be visible all at once.
Created attachment 639930 [details]
Expanded dropdown (Stock browser - Tablet)
(In reply to Michael Comella (:mcomella) from comment #0)
> Stock browser and Chrome are also unable to scroll. Chrome (phone) displays
> a improperly placed scrollbar but does not scroll.
On a Galaxy Nexus with ICS it works in both the stock browser and Chrome, for me. The stock browser glitches while scrolling it but it's generally usable. I got it to scroll the first time I loaded it in nightly, but it hasn't worked since then, which is odd. I'll debug it to see what's going on.
It looks like this happens on any subdocument scrolling when the page has touch listeners registered. The code from PanZoomController.onTouchStart gets run after the Panning:Override message comes in from browser.js. One of the first things PanZoomController.onTouchStart does is call mSubscroller.cancel() which cancels the panning override behaviour, which aborts subdocument scrolling.
Likely a regression from bug 744518 which made the browser.js Panning:Override code run earlier (before the PanZoomController.onTouchStart code).
Created attachment 640248 [details] [diff] [review]
We need to make sure we do subscroller.cancel() earlier on the touch event handling, so this code makes it happen before we even dispatch the event to gecko for processing.
*** Bug 771750 has been marked as a duplicate of this bug. ***
Would like to see this go into 14 and 15 as well, requesting tracking.
Actually I guess it won't into 14 unless we're doing another point release for that, which I don't think we are.
*** Bug 772427 has been marked as a duplicate of this bug. ***
(In reply to Kartikaya Gupta (:kats) from comment #10)
> Would like to see this go into 14 and 15 as well, requesting tracking.
Is this a regression from 14.0? If bug 744518 is the culprit, it wouldn't appear so.
This issue was fixed on the latest Nightly build.
Closing bug as verified fixed on:
Firefox 16.0a1 (2012-07-11)
Device: Galaxy Nexus
OS: Android 4.0.4
(In reply to Alex Keybl [:akeybl] from comment #13)
> Is this a regression from 14.0? If bug 744518 is the culprit, it wouldn't
> appear so.
I'm not sure what you mean by "regression from 14.0". This bug occurs in 14 (all released versions), 15, and 16. We didn't catch it before shipping but I think it's severe enough to uplift to any more releases we do on 14.
(In reply to Kartikaya Gupta (:kats) from comment #15)
> (In reply to Alex Keybl [:akeybl] from comment #13)
> > Is this a regression from 14.0? If bug 744518 is the culprit, it wouldn't
> > appear so.
> I'm not sure what you mean by "regression from 14.0".
Is this bug present on 14.0, or has it regressed since? It sounds like it was present on 14.0. Given that, the fact that this hasn't been a major pain point for users, and we're past our last planned beta, I'm wontfixing for FF14.
Yeah, makes sense.
Comment on attachment 640248 [details] [diff] [review]
[Approval Request Comment]
Bug caused by (feature/regressing bug #): 744518
User impact if declined: panning subdocuments (iframes, overflow:scroll, etc) on pages which have touch event listeners doesn't work
Testing completed (on m-c, etc.): verified on m-c
Risk to taking this patch (and alternatives if risky): mobile-only. i'd say low risk but this code is fairly brittle and hard to get right.
String or UUID changes made by this patch: none
*** Bug 773696 has been marked as a duplicate of this bug. ***
Apparently I'm dsylexic and landed the above patch with the wrong bug number. fd673fa4d1d7 actually belongs to bug 771575, not this bug.
*** Bug 782055 has been marked as a duplicate of this bug. ***