Closed Bug 746679 Opened 9 years ago Closed 9 years ago

In-content touch navigation and interactions are denied after viewing


(Firefox for Android :: General, defect)

Not set



Firefox 14
Tracking Status
blocking-fennec1.0 --- beta+


(Reporter: aaronmt, Assigned: wesj)




(Keywords: regression)


(1 file, 1 obsolete file)

After viewing a WebGL demo, such as MineGL from [1] and attempting to interact with it by pinch-zooming in, upon hitting the device back button all in-content capabilities such as touch navigation, flings, scrolls, zooming are prohibited. The only way to restore this is to switch tabs, execute an interaction and then switch back to the bad tab.

This is a loss of basic functionality in the browser.

Above was tested on an inbound build [1] on a Galaxy Nexus (Android 4.0.4)

[1] 20120418104319
So far I'm only seeing this on Paul's lovely demos. Blocking -?
This seems to happen on any site that does preventDefault in combination with touch events, I see it with this relatively simple testcase too:
Keywords: regression
Think I've got a fix for this.
Assignee: nobody → wjohnston
Attached patch Patch (obsolete) — Splinter Review
We aren't resetting to the correct state when we switch tabs.
Attachment #616663 - Flags: review?(bugmail.mozilla)
blocking-fennec1.0: ? → beta+
Summary: In-content touch navigation and interactions are denied after viewing and interacting with WebGL → In-content touch navigation and interactions are denied after viewing
Comment on attachment 616663 [details] [diff] [review]

Review of attachment 616663 [details] [diff] [review]:

I don't think this is right. mDispatchEvents needs to be reset to true for each down event we get, and should remain true unless processEventBlock(false) is called on a block. I think the correct fix here is to add "mDispatchEvents = true" in both of the isDownEvent() conditional blocks in this file.
Attachment #616663 - Flags: review?(bugmail.mozilla) → review-
Attached patch Patch v2Splinter Review
I've talked myself into putting things into the isDownEvent section of handleEvent. Essentially that just ensures that we're either going to queue this event block of dispatch it to java. If we hear from content to preventDefault we'll do neither, but that should never be our default behavior for a block of events.

The second isDownEvent call is in processEventBlock, and just keeps us from processing all the way through the queue. I don't think we want to flip things there. If we get events, we'll either queue them, or if somehow mQueueEvents = false, we'll start dispatching things out of order. In fact, we probably could make sure we continue queuing and NOT dispatching at that point (although it seems a bit paranoid).
Attachment #616663 - Attachment is obsolete: true
Attachment #616969 - Flags: review?(bugmail.mozilla)
Comment on attachment 616969 [details] [diff] [review]
Patch v2

Review of attachment 616969 [details] [diff] [review]:

You're right, this is correct and what I had in mind was not. For future reference, the way I'm thinking about this now is that we only care about the value of mDispatchEvents when mHoldInQueue is false. Therefore we should set mDispatchEvents whenever we set a value to mHoldInQueue that could be false. With your patch this condition is satisfied, so it should be correct. Assigning to mDispatchEvents in the other isDownEvent condition is not necessary, and can only hurt.
Attachment #616969 - Flags: review?(bugmail.mozilla) → review+
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 14
Duplicate of this bug: 746509
Verified/fixed on:
Nightly/15.0a1 2012-05-02
Device: Motorola Droid Pro /Samsung Galaxy S2 
OS: Android 2.3.4
You need to log in before you can comment on or make changes to this bug.