Failure: controller.waitForPageLoad(): Timeout waiting for page loaded.



Mozilla QA
Mozmill Tests
5 years ago
2 years ago


(Reporter: Andrei Eftimie, Unassigned)



Firefox Tracking Flags

(firefox20 affected, firefox21 affected, firefox22 affected, firefox27 affected, firefox30 affected, firefox-esr24 affected)


(Whiteboard: [mozmill-test-failure])



5 years ago
Happens on and off. On multiple tests.
Have not found a reliable reproductible scenario yet.

It does appear to happen more in resource constrained environments.
I am starting to suspect a more abstract / underlying issue here, but am not familiar enough with Mozmill's code yet.

Basically a page appears to not ever load (or fire the appropriate event).
Observed this on local pages (chrome://..) where the page appeared to be fully loaded, but firefox was still "loading" it (spinning wheel in tab-icon) apparently forever.

A recent list of failures:

Possible duplicates (most of them have been resolved with WORKSFORME):
-- there might be other real problems within them, but they might just be the same underlying issue --
bug 665900
bug 758151
bug 760411
bug 767821
bug 767822
bug 779488
bug 794750


We should gather all reports here, maybe we'll find a common denominator that will help us identify this issue.
(In reply to Andrei Eftimie from comment #0)
> Observed this on local pages (chrome://..) where the page appeared to be
> fully loaded, but firefox was still "loading" it (spinning wheel in
> tab-icon) apparently forever.

Do you have an example or can you reproduce this problem?
Priority: -- → P3
Whiteboard: [mozmill-test-failure]
Duplicate of this bug: 794750
Duplicate of this bug: 758151
Duplicate of this bug: 665900
Duplicate of this bug: 760411

Comment 6

5 years ago
Happened in /testSecurity/testSafeBrowsingNotificationBar.js on Linux Ubuntu 12.10 (x86) and Aurora on 1/26:
status-firefox20: --- → affected
Duplicate of this bug: 835248

Comment 8

5 years ago
Happened again today (2013-02-03) in /testSecurity/testGreenLarry.js on Mac OS X 10.6.8 (x86_64) - Firefox 21.0a1:

Comment 9

5 years ago
Another 3 failed runs while trying to load the following URL:
All on 20.0a2 on WinXP, Vista and 7 in /testToolbar/testStopReloadButtons.js :

Comment 10

5 years ago
(In reply to mario garbi from comment #8)
> Happened again today (2013-02-03) in /testSecurity/testGreenLarry.js on Mac
> OS X 10.6.8 (x86_64) - Firefox 21.0a1:
> 0dbaa964aec88a2f5637c68c9689a151

The security tests try to load the following URL:
which returns a 404.
(Its still a pretty formated 404, and has the green badge, but am wondering if it can have an effect on our tests failing)
No, that shouldn't make a difference here.
This failure most likely is responsible for all of mess we have today with the OS X machines. Please start working on it as a team and figure out why we are failing that much here. Thanks.
Priority: P3 → P1
Whiteboard: [mozmill-test-failure] → [mozmill-test-failure] s=130204 u=failure c=mozmill p=1
Blocks: 809124
No longer blocks: 809124
Andrei wants to fire off a new thread on the public mailing list for discussion but to quickly wrap up my comments on those issues:

* Our tests were failing because AMO didn't work as expected from within the MV network. It seems to be fixed now but we might want to see those issues again. It's a reason why I want to see all those boxes in MPT for better stability. But those failures showed real problems.

* The modal dialog failures happen because Firefox pings AMO for compatibility updates when installing an extension or theme. We might want to stop that. Lets further discuss this on bug 809124.

* Updating Mozmill for an additional check for DOMContentLoaded as Andrei pointed out may be helpful but we will have to check the impact of this patch. All this code is very complicated and there is a high risk for a regression. Also we most likely wouldn't take it for Mozmill 1.5.

* We might want to check functional tests which load pages on AMO and update them for local pages or pages on


5 years ago
Assignee: nobody → andrei.eftimie
Blocks: 840810
No longer blocks: 840810
Duplicate of this bug: 840810
Duplicate of this bug: 657643

Comment 16

5 years ago
We had another failure on waitForPageLoad on a local page:
status-firefox21: --- → affected

Comment 17

5 years ago
We had another couple of failures with "WaitForPageLoad" :
Happened today over testSearch/testSearchSelection.js, with 10.6.8 OS X, Nightly it locale:

Comment 19

5 years ago
Failed in /testLayout/testNavigateFTP.js, Nightly, Mac OS X 10.7.5, de:

Comment 20

5 years ago
Happened again over over "testSearch/testSearchSelection.js" with Firefox 23.0a1 de on Windows NT 6.2.9200:

Comment 21

5 years ago
Happened today on Aurora FR with MAC OS 10.6.8:
status-firefox22: --- → affected
Was anyone ever able to reproduce this locally? If yes, a HTTP log would be quite helpful here:

Comment 23

5 years ago
Happened again today on Mac OS X 10.8.2 (x86_64) with Firefox 23.0a1 fr
View the build in Jenkins:

View the results in the Mozmill Dashboard:
Actually this is most likely nothing we can do and should do in our tests. This is basically the fault of Mozmill and its broken waitForPageLoad behavior. I fixed that in bug 760720 but we most likely don't want to spend our time on backports.

We will see this failure for sure on and off but we will not fix it. We have to live with it until we make use of Mozmill 2.0.

Otilia, please find another entry as replacement.


5 years ago
Whiteboard: [mozmill-test-failure] s=130204 u=failure c=mozmill p=1 → [mozmill-test-failure]
Duplicate of this bug: 904543
Duplicate of this bug: 888182
Assignee: andrei.eftimie → nobody
Priority: P1 → P2
Happened again on Windows 7 with Nightly, locale de
Happened twice yesterday on Linux 13.04 and OS X 10.6.8, both Nightly de:
status-firefox27: --- → affected
testNavigateFTP.js has failed today on Ubuntu 12.04, default, it locale:
Which line failed in detail for this test? It might be that a click was not successful. That's important information I miss via the last comment.
Hm, I don't see the details when hovering over the failure, I get only the scrollbars and some empty canvases. Neither by inspecting the element, the last div seems to be just empty.
Same applies to other failure reports, not sure when the dashboard got this issue.
File a dashboard issue and check the raw report for the information?
In the test is at:

In controller.js:

            testNavigateFTP@resource://mozmill/modules/frame.js -> file:///home/mozauto/jenkins/workspace/mozilla-central_remote/data/mozmill-tests/firefox/tests/remote/testLayout/testNavigateFTP.js:18
        controller.waitForPageLoad(): Timeout waiting for page loaded.
I think we should enhance the waitForPageLoad method in Mozmill so it gives us more information about the load status of the page when the timeout happens. Andreea, can you please file that bug?
Sure, filed bug 957973.
Duplicate of this bug: 974586

Comment 37

4 years ago
We had about 5 failures today on Windows machines with test /testLayout/testNavigateFTP.js

Firefox Beta 28.0 pl - Windows 7 64 (mm-win-7-64-4)

Firefox Beta 28.0 ru - Windows Vista 32 (mm-win-vista-32-4)

Firefox Beta 28.0 ru - Windows 8.1 32 (mm-win-81-32-3)

Firefox Beta 28.0 pt-BR - Windows 8 64 (mm-win-8-64)

Firefox Beta 28.0 ru - Windows 7 32 (mm-win-7-32-1)
Failed on testAddons_InstallAddonWithoutEULA/test1.js on Win 8.1, default de:

Failed on /testLayout/testNavigateFTP.js on Win 8.1, default en-US:

Failed on /testAddons/testSearchAddons.js on Win 8.1, esr24 en-US:

Note: These all were on the same machine win-81-64-3 which had some issues - bug 978684.
status-firefox30: --- → affected
status-firefox-esr24: --- → affected

Comment 39

4 years ago
We had failures today in /testLayout/testNavigateFTP.js

-- Windows XP 32, Aurora de.
-- Windows 7 64, Aurora de.
-- Windows 7 32, Aurora fr.
-- Windows 7 64, Aurora fr.
-- Windows 7 32, Nightly de
-- Windows 7 64, Nightly fr
-- Windows 7 64, Nightly de
-- Windws 8 64, Nightly de

Comment 40

4 years ago
Failure today in testLayout\testNavigateFTP.js on Nightly fr (20140325030201) Windows Vista 32 (mm-win-vista-32-4)
message: "controller.waitForPageLoad(URI=, readyState=complete)"
testNavigateFTP failed several times today on windows machines:

Comment 42

4 years ago
Interesting when we fail for local pages:
> controller.waitForPageLoad(URI=, readyState=interactive)
This failed 4 times today with Beta,I tried to reproduce it locally but I couldn't reproduce it, I ran a complete testrun and the failing test for 50 times, so I don't think this is related to the new added locales but just network issue.
Nothing we want to fix for Mozmill. The adequate Firefox UI Tests issue is covered by bug 1206000.
Last Resolved: 2 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.