Open Bug 1339326 Opened 7 years ago Updated 1 year ago

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

Categories

(Toolkit :: Find Toolbar, defect)

Product:
Toolkit
Component:
Find Toolbar
Type:
defect

Tracking

()

Tracking Flags:
Tracking Status
firefox57 --- disabled
firefox58 --- disabled
firefox59 --- disabled

People

(Reporter: intermittent-bug-filer, Unassigned)

Details

(Keywords: intermittent-failure, leave-open, 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)

(In reply to Noemi Erli[:noemi_erli] from comment #107)

Brian, could you please take a look at these failures? https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?startday=2019-09-04&endday=2019-09-11&tree=trunk&bug=1339326

https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=266083503&repo=autoland&lineNumber=20458

It stared to spike since September 9th. Could this be related to Bug 1576781?

No, I don't think this could be related. Bug 1576781 adds some functionality which isn't yet used anywhere.

Flags: needinfo?(bhackett1024)

In the last 7 days there were 36 failures associated with this bug: https://treeherder.mozilla.org/intermittent-failures.html#/bugdetails?startday=2019-09-13&endday=2019-09-20&tree=all&bug=1339326
Recent failure log: https://treeherder.mozilla.org/logviewer.html#/jobs?job_id=267135687&repo=autoland&lineNumber=20357
Occurs on macosx1014-64-shippable, macosx1014-64 opt and debug build types.

Summary: Intermittent toolkit/content/tests/chrome/test_bug331215.xul | Findfield status attribute should not have been 'notfound' after entering latest → Intermittent toolkit/content/tests/chrome/test_bug331215.xhtml,test_bug331215.xul | Findfield status attribute should not have been 'notfound' after entering latest
Severity: normal → S3
You need to log in before you can comment on or make changes to this bug.