On Beta, this is happening pretty frequently on Linux. Any ideas what might be going on here, Mike?
Assignee: nobody → mdeboer
Status: NEW → ASSIGNED
Skipped on Linux for frequent failures on Beta. https://hg.mozilla.org/releases/mozilla-beta/rev/62642f364822
Not actively working on this atm.
Assignee: mdeboer → nobody
Status: ASSIGNED → NEW
In the last 7 days there have been 47 failures. Most of the failures occur on the windows7-32-stylo-disabled platform. There are also some that occur on Windows 7 and very low number on oher platforms like: OS X 10.10, linux32-stylo-disabled, windows10-64. The failures occur only on the debug build type. Here is an example of a recent log: https://treeherder.mozilla.org/logviewer.html#?repo=mozilla-central&job_id=141199110&lineNumber=15843 And a relevant snippet of the log: 00:41:29 INFO - 967 INFO Starting test with browser 'content-remote' 15841 00:41:29 INFO - 968 INFO TEST-PASS | toolkit/content/tests/chrome/test_bug331215.xul | Findfield status attribute should have been 'notfound' after entering test 15842 00:41:29 INFO - Buffered messages finished 15843 00:41:29 ERROR - 969 INFO TEST-UNEXPECTED-FAIL | toolkit/content/tests/chrome/test_bug331215.xul | Findfield status attribute should not have been 'notfound' after entering latest 15844 00:41:29 INFO - onDocumentLoaded@chrome://mochitests/content/chrome/toolkit/content/tests/chrome/bug331215_window.xul:66:7 15845 00:41:29 INFO - async*startTestWithBrowser@chrome://mochitests/content/chrome/toolkit/content/tests/chrome/bug331215_window.xul:53:13 15846 00:41:29 INFO - async*startTest/<@chrome://mochitests/content/chrome/toolkit/content/tests/chrome/bug331215_window.xul:38:17 15847 00:41:29 INFO - async*startTest@chrome://mochitests/content/chrome/toolkit/content/tests/chrome/bug331215_window.xul:35:14 Starting with October 30th, we can see a significant increase in failures. :mikedeboer, could you please take a look?
Whiteboard: [stockwell needswork]
(In reply to Tiberius Oros[:tiberius_oros] from comment #31) > The failures occur only on the debug build type. In other words: if I can find a suitable solution for this intermittent, a valid course of action would be to disable this test on debug builds?
Flags: needinfo?(mdeboer) → needinfo?(toros)
Yes. If you or anyone else can't find a solution for this intermittent, then we will disable it on debug.
Flags: needinfo?(toros) → needinfo?(mdeboer)
Pushed by email@example.com: https://hg.mozilla.org/integration/mozilla-inbound/rev/b8fde5e05003 Disable toolkit/content/tests/chrome/test_bug331215.xul on windows debug for frequent failures. r=me, a=testonly
keep in mind this is disabled and will need to be re-enabled when working on a fix.
Whiteboard: [stockwell disable-recommended] → [stockwell disabled]
I debugged this using our new debugger. Basically the problem is that the content process starts up and loads about:blank, that load event fires, gets forwarded as a notification to the chrome process via BrowserTestUtils, and causes the BrowserTestUtils.browserLoaded promise to be resolved (which is premature since data:text/html,latest hasn't loaded yet --- this is the root cause of the bug). After that onDocumentLoaded starts running. It triggers searches for "te", "tes" and "test", all of which return FIND_NOTFOUND results. (The test assumes all three will return FIND_FOUND and the first two ignored by promiseEnterStringIntoFindField's listener callback.) The first one causes promiseEnterStringIntoFindField("test") to resolve, the next one causes promiseEnterStringIntoFindField("l") to resolve (and the assertion that the status is "notfound" is true), and the third one causes promiseEnterStringIntoFindField("a") to resolve, causing a failure because in that case we're expecting a "found" result.
You need to log in before you can comment on or make changes to this bug.