Intermittent toolkit/content/tests/chrome/test_bug331215.xul | Findfield status attribute should not have been 'notfound' after entering latest

NEW
Unassigned

Status

()

defect
3 years ago
21 days ago

People

(Reporter: intermittent-bug-filer, Unassigned)

Tracking

({intermittent-failure, leave-open})

unspecified
Points:
---

Firefox Tracking Flags

(firefox57 disabled, firefox58 disabled, firefox59 disabled)

Details

(Whiteboard: [stockwell disabled])

Component: XUL Widgets → Find Toolbar
On Beta, this is happening pretty frequently on Linux. Any ideas what might be going on here, Mike?
Flags: needinfo?(mdeboer)
Assignee: nobody → mdeboer
Status: NEW → ASSIGNED
Flags: needinfo?(mdeboer)
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?
Flags: needinfo?(mdeboer)
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 jmaher@mozilla.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.
Keywords: leave-open
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.
Flags: needinfo?(mdeboer)
You need to log in before you can comment on or make changes to this bug.