Closed Bug 895288 Opened 7 years ago Closed 7 years ago

Intermittent browser_aboutHome.js | Test timed out | Found a tab after previous test timed out: about:blank


(Firefox :: General, defect)

Not set



Firefox 25
Tracking Status
firefox24 --- fixed
firefox25 --- fixed


(Reporter: ttaubert, Assigned: mak)



(Keywords: intermittent-failure)


(1 file)
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_aboutHome.js | Test timed out
TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/base/content/test/browser_aboutHome.js | Found a tab after previous test timed out: about:blank

It is over the 60 seconds timeout, could be the box was strangely slow and it took more time, we may bump up the timeout to 90s and see.

INFO TEST-END | chrome://mochitests/content/browser/browser/base/content/test/browser_aboutHome.js | finished in 80285ms
The timeout fired 2 seconds earlier and the test was doing stuff just before the timeout.
Assignee: nobody → mak77
No longer blocks: 890409
Actually the long time looks due to loading the google search page, it prints a very high amount of console log due to css errors.
after 30s we start the health report test, and it alone takes almost 1 minute. We should try to block loading earlier.
also, our timeout handling in b-c should better notify us.
In this case it was clear the test was not hanging, cause it just printed a TEST-INFO. It's good to be notified of tests taking too much, but it should not appear as a common timeout. Instead of "timed out" it should tell us "Interrupted due to taking too long time to complete".
I think this is feasible, we can track when the last output happened at least.
Depends on: 895376
(In reply to Marco Bonardo [:mak] from comment #2)
> Actually the long time looks due to loading the google search page, it
> prints a very high amount of console log due to css errors.

Is that possibly related to bug 845205 comment 36? Maybe this failure was triggered only while that patch was in the tree?
No, I don't think so, it is a bunch of css errors in the console, not assertions. Stuff like "invalid background... bla bla bla". Also, health report takes quite some time to do its job, not sure why.
Attached patch home.diffSplinter Review
this should improve the time taken by the test, by stopping the load even earlier.
Attachment #778159 - Flags: review?(ttaubert)
The last statement before the long pause is:

19:10:34 | TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_aboutHome.js | Searches provider is available.

The next one after the pause is:

19:11:27 | TEST-PASS | chrome://mochitests/content/browser/browser/base/content/test/browser_aboutHome.js | One more search recorded.

To me this seems like this took almost a minute to complete:

provider.getMeasurement("counts", 2).getValues().then(data => { /* do stuff */ });

I don't think this would be fixed by moving gBrowser.stop() around, would it? I have no idea how the healthReporter is implemented but I wonder if maybe something went wrong in the backend?
First of all I want to remove those hundreds very long css warnings from the console, those are also slowing down everything.
Locally I don't see any issue in getMeasurement, but I also don't see those css warnings.
Comment on attachment 778159 [details] [diff] [review]

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

Ok, fair enough.
Attachment #778159 - Flags: review?(ttaubert) → review+

I will take a look at the next logs and check time differences, if still unexpectedly high, I will file a bug to investigate why HR takes so much time.
Target Milestone: --- → Firefox 25
Closed: 7 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.