Closed Bug 965381 Opened 7 years ago Closed 7 years ago

[B2G][Facebook] Facebook Pages aren't loaded from menu

Categories

(Core :: Panning and Zooming, defect)

28 Branch
ARM
Gonk (Firefox OS)
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla30
blocking-b2g 1.3+
Tracking Status
firefox28 --- wontfix
firefox29 --- fixed
firefox30 --- fixed
b2g-v1.2 --- unaffected
b2g-v1.3 --- fixed
b2g-v1.3T --- fixed
b2g-v1.4 --- fixed

People

(Reporter: sarsenyev, Assigned: kats)

References

Details

(Keywords: regression, Whiteboard: dogfood1.3)

Attachments

(4 files, 3 obsolete files)

No description provided.
Attached file log12914.txt
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
Summary: [B2G][Facebook] Facebook Pages arenload from menu → [B2G][Facebook] Facebook Pages aren't loaded from menu
Whiteboard: dogfood1.3
Can you include a video of the bug?
blocking-b2g: --- → 1.3?
Keywords: qawanted, regression
Keywords: qawanted
The logcat doesn't have console enabled. We need a logcat with that enabled.
Keywords: qawanted
Attached file log12914-2.txt
Logcat with Console Enabled
Keywords: qawanted
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
blocking-b2g: 1.3? → 1.3+
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.
Does this reproduce with APZC disabled on 1.3?
Keywords: qawanted
QA Contact: mvaughan
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
Keywords: qawanted
Interestingly enough, this works on facebook.com for me, but fails (is reproducible) using the facebook that gets installed to the homescreen.
Component: General → Panning and Zooming
Product: Firefox OS → Core
Version: unspecified → 28 Branch
Let's say tentatively that this is APZC, as bug 907179 changes are in the regression range.
Assignee: nobody → bugmail.mozilla
Whiteboard: dogfood1.3 → dogfood1.3, [ETA: 2/21]
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.
Attached patch Patch (obsolete) — Splinter Review
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).
Attachment #8371861 - Flags: review?(dale)
Attached patch Patch v2 (obsolete) — Splinter Review
Updated to make the tests pass and document how the tests exercise the new behaviour.
Attachment #8371861 - Attachment is obsolete: true
Attachment #8371861 - Flags: review?(dale)
Attachment #8372303 - Flags: review?(dale)
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
Attached patch Patch v2 (rebased) (obsolete) — Splinter Review
Rebased
Attachment #8372303 - Attachment is obsolete: true
Attachment #8372303 - Flags: review?(dale)
Attachment #8373351 - Flags: review?(dale)
Attached patch Patch v3Splinter Review
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).
Attachment #8373351 - Attachment is obsolete: true
Attachment #8373351 - Flags: review?(dale)
Attachment #8373352 - Flags: review?(dale)
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
Attachment #8373352 - Flags: review?(dale) → review+
Ugh, I got bit by bug 970341 again when I made my last change to the test. I will fix and reland.
Flags: needinfo?(bugmail.mozilla)
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.
https://hg.mozilla.org/mozilla-central/rev/952941bc168d
Status: NEW → RESOLVED
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: dogfood1.3, [ETA: 2/21] → dogfood1.3
Target Milestone: --- → mozilla30
Waiting for Doug to make bug 964421 stick on 1.3 before I can uplift this.
Whiteboard: dogfood1.3 → dogfood1.3 [branch-patch-needed]
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
Attachment #8373352 - Flags: approval-mozilla-aurora?
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?
Flags: needinfo?(bugmail.mozilla)
Yup. I just marked it as wontfix because there was previously no reason to uplift the patch.
Flags: needinfo?(bugmail.mozilla)
OK. thanks for the quick feedback!
Attachment #8373352 - Flags: approval-mozilla-aurora? → approval-mozilla-aurora+
You need to log in before you can comment on or make changes to this bug.