Closed Bug 947550 Opened 11 years ago Closed 9 years ago

Intermittent testAboutHomePageNavigation | Waiting for HomePager {BOOKMARKS,TOP_SITES} page. -

Categories

(Firefox for Android Graveyard :: General, defect)

Product:
Firefox for Android Graveyard
Component:
General
Platform:
ARM
Android
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

(firefox27 unaffected, firefox28 fixed, firefox29 fixed, firefox30 fixed, firefox-esr24 unaffected)

Status:
RESOLVED WORKSFORME
Milestone:
Firefox 30
Tracking Flags:
Tracking Status
firefox27 --- unaffected
firefox28 --- fixed
firefox29 --- fixed
firefox30 --- fixed
firefox-esr24 --- unaffected

People

(Reporter: KWierso, Unassigned)

References

Details

(Keywords: intermittent-failure, Whiteboard: [leave-open][test disabled])

Attachments

(2 files, 2 obsolete files)

Use Robotium side swipe methods.
5.82 KB, patch
Margaret
: review+
Details | Diff | Splinter Review
Wait for Gecko:DelayedStartup in testAboutHomePageNavigation.
2.85 KB, patch
Margaret
: review+
Details | Diff | Splinter Review 
https://tbpl.mozilla.org/php/getParsedLog.php?id=31590999&tree=Fx-Team
slave: tegra-053


Similar to bug 947177?


1 INFO TEST-START | testAboutHomePageNavigation
2 INFO TEST-PASS | testAboutHomePageNavigation | Given message occurred for registered event - Gecko:Ready should equal Gecko:Ready
EventExpecter: no longer listening for Gecko:Ready
3 INFO TEST-PASS | testAboutHomePageNavigation | The HomePager is visible - 0 should equal 0
4 INFO TEST-PASS | testAboutHomePageNavigation | The HomePager is visible - 0 should equal 0
5 INFO TEST-PASS | testAboutHomePageNavigation | The current HomePager page is TOP_SITES - 1 should equal 1
6 INFO TEST-PASS | testAboutHomePageNavigation | The HomePager is visible - 0 should equal 0
7 INFO TEST-PASS | testAboutHomePageNavigation | The HomePager's PagerAdapter is not null - org.mozilla.gecko.home.HomePager$TabsAdapter@485f7bc8 should not equal null
8 INFO TEST-UNEXPECTED-FAIL | testAboutHomePageNavigation | Waiting for HomePager BOOKMARKS page. - 
9 INFO TEST-END | testAboutHomePageNavigation | finished in 18848ms
> Similar to bug 947177?

Same bug, however, the debug output is different depending on whether you're on phone (Android v2.2 as per this bug) or tablet (all other try builds as per bug 947177) due to bug 947527.

I'll try to fix that so we can dupe these.
Assignee: nobody → michael.l.comella
Status: NEW → ASSIGNED
bug 947177 comment 2 has some (potentially) useful speculation:

> This occurs after swiping from the initial page to the page on the right on an armv6 device. I have
> had this error happen locally where the issue is caused by the device not registering a full swipe to
> the next screen (typically because it is hanging/slow), thus scrolling back to the page it was
> initially on.
>
> Some ideas:
>  * Automatic retry if HomePager.getCurrentItem() does not change between swipes (con: We really
> shouldn't *have* to do this)
>  * Wait a bit after each swipe to give the fragment more time to load and settle? The time between-
> swipes seems very short and inhuman (con: longer tests)
Summary: Intermittent testAboutHomePageNavigation | Waiting for HomePager BOOKMARKS page. - → Intermittent testAboutHomePageNavigation | Waiting for HomePager {BOOKMARKS,TOP_SITES} page. -
Attached patch Use Robotium side swipe methods. (obsolete) — — Splinter Review 
I used Robotium's side swipe methods which are slower and seemingly more stable
than our custom GestureHelper methods. As such, I also removed GestureHelper.

try run for this patch:
  https://tbpl.mozilla.org/?tree=Try&rev=846e6e0c121d
Comment on attachment 8346201 [details] [diff] [review]
Use Robotium side swipe methods.

Passed the first try run and I'm too lazy to wait for the others to finish. x_x I think it would be better just to shove it onto inbound and see if the intermittents stop since it'll get a lot more coverage. I'm skeptical if try even uses all of the same devices because my previous try runs for the original framework patch never failed.

See comment 15 for info on what this patch changes. Additionally, I removed the "swipe should take a direction?" TODO because it's harder to figure out how to use such a method (does this swipe in that direction? Does this move to the page in that direction) than swipeToPageOnRight.
Attachment #8346201 - Flags: review?(margaret.leibovic)
Comment on attachment 8346201 [details] [diff] [review]
Use Robotium side swipe methods.

Review of attachment 8346201 [details] [diff] [review]:
-----------------------------------------------------------------

Sorry for the slow review, this looks good to me! Let's just make sure we watch out for any new intermittents that might show up.

::: mobile/android/base/tests/components/AboutHomeComponent.java
@@ +77,3 @@
>      public AboutHomeComponent swipeToPageOnRight() {
>          mTestContext.dumpLog("Swiping to the page on the right.");
> +        swipeToPage(Solo.RIGHT);

Nice, this is more intuitive now :)
Attachment #8346201 - Flags: review?(margaret.leibovic) → review+
https://hg.mozilla.org/mozilla-central/rev/d0127fcb33e1
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → FIXED
Target Milestone: --- → Firefox 29
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
The browser tends to run slowly right after Gecko:Ready is received and these errors seem to happen only on the first swipe so I think if we pause for a few seconds before starting this test, it might solve the problems here (but it's a sad hack). I wonder if there isn't another message we can wait for after Ready?
Chose the value by being somewhat arbitrary and ensuring it performs well on my
Galaxy Nexus.

Not worth pushing to try because it doesn't fail often enough.
Attachment #8368963 - Flags: review?(margaret.leibovic)
Comment on attachment 8368963 [details] [diff] [review]
Wait for a few seconds before testAboutHomePageNavigation.

Review of attachment 8368963 [details] [diff] [review]:
-----------------------------------------------------------------

How about waiting for the new "Gecko:DelayedStartup" instead? I would assume that fires after the aboutHome.xhtml DOMContentLoaded.

Adding a sleep at the beginning of the test feels a bit :/
Does aboutHome.xhtml get loaded automatically on about:home?
(In reply to Michael Comella (:mcomella) from comment #45)
> Does aboutHome.xhtml get loaded automatically on about:home?

I believe so, since that's what's actually about:home (the whole Java UI is just a thing we show on top of that).
Seems to work well enough on my Galaxy Nexus - nice idea.
Attachment #8370527 - Flags: review?(margaret.leibovic)
Attachment #8368963 - Attachment is obsolete: true
Attachment #8368963 - Flags: review?(margaret.leibovic)
Comment on attachment 8370527 [details] [diff] [review]
Wait for Gecko:DelayedStartup in testAboutHomePageNavigation.

Review of attachment 8370527 [details] [diff] [review]:
-----------------------------------------------------------------

:)
Attachment #8370527 - Flags: review?(margaret.leibovic) → review+
https://hg.mozilla.org/mozilla-central/rev/71118c075821
Status: REOPENED → RESOLVED
Closed: 11 years ago → 10 years ago
Resolution: --- → FIXED
Backed out in https://hg.mozilla.org/integration/fx-team/rev/71118c075821 because things it depended on were backed out in https://tbpl.mozilla.org/?tree=Fx-Team&onlyunstarred=1&rev=d45483106791
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Reminder for me to reland this.
Depends on: 964510
Flags: needinfo?(michael.l.comella)
Flags: needinfo?(michael.l.comella)
https://hg.mozilla.org/mozilla-central/rev/efedd01c7fbc

NB: it's possible this bug's target milestone needs updating, I can't tell from a casual look at the bug
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
status-firefox28: fixed → affected
status-firefox29: fixed → affected
status-firefox30: --- → fixed
Target Milestone: Firefox 29 → Firefox 30
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #56)
> Beta didn't like it. Oh well.

This is dependent on bug 964510, which appears to be in 29 (the backout never got uplifted [1]), but not 28.

[1]: https://bugzilla.mozilla.org/show_bug.cgi?id=964510#c9
That would definitely explain it. Oh well, it would have been nice to have on 28, but I'm not losing any sleep over it :)
comment 59 is not the last swipe, like comment 60 and comment 61. Not sure what's going on here.
Sounds like REOPENED to me.
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Brian, retriggers on fx-team are pointing to bug 962103 as the cause of the recent surge in this failure (and probably bug 977952). Can you please take a look?
Flags: needinfo?(bnicholson)
(In reply to Ryan VanderMeulen [:RyanVM UTC-5] from comment #73)
> Brian, retriggers on fx-team are pointing to bug 962103 as the cause of the
> recent surge in this failure (and probably bug 977952). Can you please take
> a look?

Bug 962103 has been backed out (the failure rate was much too high for it to stay landed; it should have been backed out earlier)
Status: REOPENED → RESOLVED
Closed: 10 years ago → 10 years ago
Resolution: --- → FIXED
Flags: needinfo?(bnicholson)
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Whiteboard: [leave-open][test disabled]
Assignee: michael.l.comella → nobody
Status: REOPENED → RESOLVED
Closed: 10 years ago → 9 years ago
Resolution: --- → WORKSFORME
Product: Firefox for Android → Firefox for Android Graveyard
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: