Closed Bug 938969 Opened 11 years ago Closed 11 years ago

Intermittent in testAboutHomeVisibility: got http://mochi.test:8888/tests/robocop/robocop_blank_01.html, expected Browser Blank Page 01

Categories

(Firefox for Android Graveyard :: Testing, defect)

All
Android
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED DUPLICATE of bug 946656

People

(Reporter: mcomella, Assigned: mcomella)

References

Details

(Keywords: intermittent-failure)

Attachments

(1 file)

bug 910859 introduces the testAboutHomeVisibility test which has failed for me intermittently. However, I'm not sure if my device was using an old (or WIP) fennec build at the time. This bug is here to followup and track any possible intermittent failures.
Component: General → Testing
This may have been solved in the original bug; see bug 910859 comment 69.
via bug 910859 comment 86: > Intermittent in try from bug 910859 comment 82 - I'm holding landing until I can figure this out. > It occurred on 2.2 armv6 so it's possible our timeout is too short (though the hasTimedOut > message is not in the output, so perhaps not. > Here's a try push with a longer timeout (2000->5000): > https://tbpl.mozilla.org/?tree=Try&rev=7c9f65e32fa0
Summary: Possible intermittent test failure in testAboutHomeVisibility → Intermittent in testAboutHomeVisibility: got http://mochi.test:8888/tests/robocop/robocop_blank_01.html, expected Browser Blank Page 01
This could also be a network error: later in the file (granted, after a minute and the start of another test) we get: 11-27 03:07:33.042 I/GeckoSuggestClient( 8314): Not connected to network ... 11-27 03:07:36.372 E/LoadFaviconTask( 8314): java.net.UnknownHostException: mochi.test This is after a page has loaded, meaning the connection could just have been spotty.
Assignee: nobody → michael.l.comella
Status: NEW → ASSIGNED
Precedent exists for this issue in BaseTest - see bug 915350 and bug 943310.
Attached file local repro - stderr (deleted) —
I was able to repro locally with some more useful debug output. The event to change the title is "DOMTitleChanged" which notably fires *after* the toolbar title has been asserted.
try run waiting for both DOMContentLoaded and DOMTitleChanged in WaitHelper.waitForPageLoad: https://tbpl.mozilla.org/?tree=Try&rev=06c1913c0ddb
The try run passed so I added a patch (#2) to bug 910859 fixing the issue by waiting on both the "DOMContentLoaded" and "DOMTitleChanged" events, as per comment 6. I will mark this as a dupe once bug 910859 lands.
Solved in bug 910859 though potentially the same issue as bug 946656.
Status: ASSIGNED → RESOLVED
Closed: 11 years ago
Resolution: --- → DUPLICATE
Forward duping to the most relevant bug on this issue.
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

Created:
Updated:
Size: