Description: When navigating pages from the menu, the pages don't load, just "Loading" icon is spinning Repro Steps: 1) Updated Buri to BuildID: 20140127004002 2) Download the Facebook from Marketplace 3) Launch the app from the home screen 4) Log in with correct credentials 5) Navigate to the menu (drawer icon) 6) Tap any page page from the menu Actual: The page is endlessly loading Expected: The pages are open with result Device: Buri 1.3 MOZ BuildID: 20140127004002 Gaia: 25a45a836a4a21a30f63fa7b544b42e8b781180a Gecko: c40099a42c1f Version: 28.0a2 Firmware Version: v1.2-device.cfg Notes: Repro frequency: 100% See attached: logcat

It doesn't reproduce on 1.2

Can you include a video of the bug?

The logcat doesn't have console enabled. We need a logcat with that enabled.

Logcat with Console Enabled

Regression Window: Last Working Environmental Variables: Device: Buri v1.3 Mozilla RIL BuildID: 20140109004002 Gaia: 22bc6be5b76cdc6d4e9667ff070979041a20ce2f Gecko: 2c8f8683bd0d Version: 28.0a2 Base Image: V1.2-device.cfg First Broken Environmental Variables: Device: Buri v1.3 Mozilla RIL BuildID: 20140110004009 Gaia: c606b129a2d1647c0fc7bfb197555026e9b27f9e Gecko: c5109884ae3a Version: 28.0a2 Base Image: V1.2-device.cfg

1.3+ for breakage of facebook

I can't reproduce this problem in an aurora b2g desktop build from yesterday or today. Eitan can't reproduce it on a ZTE Open with an m-c build from yesterday. Is this buri-specific? It seems like it's at least device-specific since I can't reproduce it with b2g desktop.

(In reply to Andrew Overholt [:overholt] from comment #9) > I can't reproduce this problem in an aurora b2g desktop build from yesterday > or today. > Eitan can't reproduce it on a ZTE Open with an m-c build from yesterday. > > Is this buri-specific? It seems like it's at least device-specific since I > can't reproduce it with b2g desktop. I don't think so. This reproduces for me on a TCL Soul device running 1.3.

Hmm, another bug that seems to reproduce on TCL Soul and Buri but not on at least one other device (ZTE Open in this case). Other than having someone with multiple devices spend a bunch of time on this, I can't think of a way to track this down.

Cannot reproduce on Nexus 4. Commits in the range from comment #7: https://github.com/mozilla-b2g/gaia/compare/22bc6be5b76cdc6d4e9667ff070979041a20ce2f...c606b129a2d1647c0fc7bfb197555026e9b27f9e

Does this reproduce with APZC disabled on 1.3?

This issue does NOT reproduce when APZC is disabled on 1.3 (using a Buri). Device: Buri v1.3 MOZ RIL BuildID: 20140203181708 Gaia: bb36b4164d3e51ca04b612e507e1178f80bf240d Gecko: 9731b0b7fa78 Version: 28.0 Firmware Version: V1.2-device.cfg

Interestingly enough, this works on facebook.com for me, but fails (is reproducible) using the facebook that gets installed to the homescreen.

Let's say tentatively that this is APZC, as bug 907179 changes are in the regression range.

The range in comment 13 includes the patch that turned on APZ. Can we get a window where QA is manually enabling APZ on builds prior to jan 10? That would be useful assuming this is an APZ issue.

Tested this with APZ turned on manually on the first build where the option to enable APZ was available, this issue has apparently been occurring since that build. Device: Buri v1.3 Mozilla RIL BuildID: 20131025100746 Gaia: afbf45f26a73b7cd5e0a831bea48087331975286 Gecko: 2f2a45f04e7c Version: 27.0a1 Base Image: V1.2-device.cfg

I'm able to reproduce this intermittently. Initial investigation of the input events delivered to content seems to indicate that in the case where it reproduces, we deliver the sequence "touchdown, touchmove, singletap, touchup" whereas in the case where it doesn't reproduce we deliver the sequence "touchdown, touchmove, touchup, singletap". When APZC is disabled we also deliver "touchdown, touchmove, touchup, singletap" so this is likely the cause of the problem. (Note that the singletap expands into mousemove, mousedown, mouseup).

I wrote a big set of patches to move the gesture handling to after the call to OnTouchEnd in APZC but it turned out that was all in vain. The problem is that we don't send the touchend to content until we return from APZC::HandleInputEvent, and so the order of stuff inside APZC::HandleInputEvent pretty much doesn't matter. The only way I can think of to do this is to do the equivalent of setTimeout(.., 0) on it. Sigh.

This seems to do the trick for me. I'll see if I can write a test for it too (and verify the existing tests still work).

Updated to make the tests pass and document how the tests exercise the new behaviour.

Very sorry, I havent had time to review this until now and its now bitrotted, as far as the code it makes sense to me, happy to test it when its rebased

Rebased

Sorry, small update - I just added an EXPECT_TRUE check to the mock implemenation of PostDelayedTask to catch cases where we clobber tasks (since I ran into that problem while rebasing this test).

Comment on attachment 8373352 [details] [diff] [review] Patch v3 This is fairly out of comfort zone for reviewing, but I understand the problem, the code looks good to me and I was able to reproduce the failure and see that the patch fixed the problem, so r+ from me, sorry for the delay

Thanks. https://hg.mozilla.org/integration/mozilla-inbound/rev/bde8b5894490

Backed out in https://hg.mozilla.org/integration/mozilla-inbound/rev/10ee018a798b for APZC test failures affecting at least Linux and OSX builds: https://tbpl.mozilla.org/php/getParsedLog.php?id=34447691&tree=Mozilla-Inbound

Ugh, I got bit by bug 970341 again when I made my last change to the test. I will fix and reland.

Ok, small fixup to the test mock object and relanded: https://hg.mozilla.org/integration/mozilla-inbound/rev/952941bc168d

We plan to demo Facebook on a phone running 1.3 at MWC2014, which starts Feb 24, so that makes this fix important to our MWC demo team.

Waiting for Doug to make bug 964421 stick on 1.3 before I can uplift this.

Comment on attachment 8373352 [details] [diff] [review] Patch v3 [Approval Request Comment] Bug caused by (feature/regressing bug #): regression windows is Gecko 26 - Gecko 28 - no bug (mupltiple APZC changes) User impact if declined: unable to use Facebook touch with APZC Testing completed (on m-c, etc.): m-c (seems b2g28 release too) Risk to taking this patch (and alternatives if risky): don't know, kats? String or IDL/UUID changes made by this patch: no

Note that the above request is for the embedlite/Sailfish port of the code. It was already uplifted to b2g28 for B2G use. Metro might be affected as well; not sure about that.

@Kartikaya, so you confirm that your tag "wontfix" for firefox 29 is no longer relevant and should be changed to affected?

Yup. I just marked it as wontfix because there was previously no reason to uplift the patch.

OK. thanks for the quick feedback!

Rebased to aurora and landed: https://hg.mozilla.org/releases/mozilla-aurora/rev/9ea122ff54b6