Closed Bug 1135545 Opened 9 years ago Closed 11 months ago

Intermittent Win8 cascade of failure starting with test_bug987230.xhtml,test_bug987230.xul | Test timed out where the screenshot shows the Start screen

Categories

(Core :: XUL, defect, P3)

Product:
Core
Component:
XUL
Platform:
x86
Windows 8
Type:
defect

Tracking

()

Status:
RESOLVED INCOMPLETE
Milestone:
mozilla41
Tracking Flags:
Tracking Status
firefox39 --- fixed
firefox40 --- fixed
firefox41 --- fixed
firefox-esr31 --- fixed
firefox-esr38 --- fixed

People

(Reporter: philor, Unassigned)

References

Details

(Keywords: intermittent-failure) 

Moving the mouse to a hot corner?
Can we ask treeherder where this first happened yet? :-(

I have no idea what would have suddenly regressed this test which has been working fine for ages now... :-\
Flags: needinfo?(philringnalda)
Nope, nor can we ask our collective memory of "haha, the screenshot shows the Start screen, how on earth did that happen?" whether this is the only one or one of several.
Flags: needinfo?(philringnalda)
Debugging shows that the window is raised, the popup opens and is set to the shown state, but the native event doesn't seem to get received. Perhaps the native event is targeting the desktop or somewhere else?

The next test appears to indicate that the browser window is still active.
See Also: → 924728
CCing some Windows RelEngers. We have a couple different bugs hitting this scenario. Any ideas how we're ending up on a Start Screen?
Flags: needinfo?(q)
Flags: needinfo?(mshal)
Flags: needinfo?(jlund)
At least all the recent history of bug 1090633 is this issue as well.
See Also: → 1090633
with logging from patch in comment 43:

14:52:01     INFO -  1960 INFO TEST-START | layout/xul/test/test_bug987230.xul
14:53:19     INFO -  1427147599802	Browser.Experiments.Experiments	TRACE	Experiments #0::updateManifest()
14:53:19     INFO -  1427147599802	Browser.Experiments.Experiments	TRACE	Experiments #0::_run
14:53:19     INFO -  1427147599802	Browser.Experiments.Experiments	TRACE	Experiments #0::_main iteration
14:53:19     INFO -  1427147599803	Browser.Experiments.Experiments	TRACE	Experiments #0::_loadManifest
14:53:19     INFO -  1427147599803	Browser.Experiments.Experiments	TRACE	Experiments #0::httpGetRequest(http://127.0.0.1:8888/experiments-dummy/manifest)
14:53:19     INFO -  1427147599811	Browser.Experiments.Experiments	ERROR	Experiments #0::httpGetRequest::onLoad() - Request to http://127.0.0.1:8888/experiments-dummy/manifest returned status 404
14:53:19     INFO -  1427147599811	Browser.Experiments.Experiments	ERROR	Experiments #0::_loadManifest - failure to fetch/parse manifest (continuing anyway): Error: Experiments - XHR status for http://127.0.0.1:8888/experiments-dummy/manifest is 404
14:53:19     INFO -  1427147599812	Browser.Experiments.Experiments	TRACE	Experiments #0::_evaluateExperiments
14:53:19     INFO -  1427147599814	Browser.Experiments.Experiments	TRACE	Experiments #0::_main finished, scheduling next run
14:53:25     INFO -  JavaScript error: resource:///modules/WindowsJumpLists.jsm, line 525: ReferenceError: _idle is not defined
14:55:25     INFO -  JavaScript error: resource:///modules/WindowsJumpLists.jsm, line 525: ReferenceError: _idle is not defined
14:57:25     INFO -  JavaScript error: resource:///modules/WindowsJumpLists.jsm, line 525: ReferenceError: _idle is not defined
14:57:31     INFO -  TEST-INFO | screenshot: exit status 0
14:57:31     INFO -  1961 INFO click: toolbarbutton-anchor
14:57:31     INFO -  1962 INFO TEST-PASS | layout/xul/test/test_bug987230.xul | Popup should only be shown once
14:57:31     INFO -  1963 INFO Sending mousedown+up for offsets: 5, 5; innerscreen: 24, 376; rect: 0, 33.
14:57:31     INFO -  1964 INFO Resulting x, y, scale: 29, 414, 1
14:57:31     INFO -  1965 INFO Final params: 29, 414
14:57:31     INFO -  1966 INFO TEST-UNEXPECTED-FAIL | layout/xul/test/test_bug987230.xul | Test timed out. - expected PASS
14:57:31     INFO -  1967 INFO MEMORY STAT vsize after test: 1023004672
14:57:31     INFO -  1968 INFO MEMORY STAT vsizeMaxContiguous after test: 8443881652224
14:57:31     INFO -  1969 INFO MEMORY STAT residentFast after test: 62939136
14:57:31     INFO -  1970 INFO MEMORY STAT heapAllocated after test: 113636000


I don't see log output from the second part added: https://hg.mozilla.org/integration/fx-team/rev/ea88cbb1b20e#l1.34


I really can't say what's going on here. I ran some stats on this particular bug and it doesn't seem to happen on a particular branch, machine, or day. likewise with 1090633 and 924728.

What we can do is loan any of our windows machines to someone familiar of mochitest-other suite. They can then run the suite over and over till this intermittent is hit.


> python diagnose_intermittent_bug.py 1135545
{'builders': [('Windows 8 64-bit mozilla-inbound debug test mochitest-other',
               14),
              ('Windows 8 64-bit mozilla-inbound opt test mochitest-other',
               13),
              ('Windows 8 64-bit fx-team opt test mochitest-other', 11),
              ('Windows 8 64-bit fx-team debug test mochitest-other', 9),
              ('Windows 8 64-bit mozilla-central debug test mochitest-other',
               5),
              ('Windows 8 64-bit b2g-inbound opt test mochitest-other', 4),
              ('Windows 8 64-bit mozilla-central pgo test mochitest-other',
               4),
              ('Windows 8 64-bit b2g-inbound pgo test mochitest-other', 4),
              ('Windows 8 64-bit mozilla-aurora debug test mochitest-other',
               3),
              ('Windows 8 64-bit b2g-inbound debug test mochitest-other', 3),
              ('Windows 8 64-bit mozilla-beta pgo test mochitest-other', 2),
              ('Windows 8 64-bit mozilla-central opt test mochitest-other',
               2),
              ('Windows 8 64-bit try opt test mochitest-other', 2),
              ('Windows 8 64-bit mozilla-inbound pgo test mochitest-other',
               2),
              ('WINNT 6.2 mozilla-b2g34_v2_1 debug test mochitest-other', 1),
              ('Windows 8 64-bit mozilla-release debug test mochitest-other',
               1),
              ('Windows 8 64-bit try debug test mochitest-other', 1)],
 'repos': [('mozilla-inbound', 29),
           ('fx-team', 20),
           ('mozilla-central', 11),
           ('b2g-inbound', 11),
           ('try', 3),
           ('mozilla-aurora', 3),
           ('mozilla-beta', 2),
           ('mozilla-b2g34_v2_1', 1),
           ('mozilla-release', 1)],
 'slaves': [('t-w864-ix-122', 4),
            ('t-w864-ix-040', 4),
            ('t-w864-ix-100', 4),
            ('t-w864-ix-055', 4),
            ('t-w864-ix-088', 3),
            ('t-w864-ix-078', 3),
            ('t-w864-ix-075', 3),
            ('t-w864-ix-114', 3),
            ('t-w864-ix-080', 2),
            ('t-w864-ix-105', 2),
            ('t-w864-ix-066', 2),
            ('t-w864-ix-065', 2),
            ('t-w864-ix-064', 2),
            ('t-w864-ix-098', 2),
            ('t-w864-ix-093', 2),
            ('t-w864-ix-090', 2),
            ('t-w864-ix-056', 2),
            ('t-w864-ix-016', 2),
            ('t-w864-ix-017', 2),
            ('t-w864-ix-070', 1),
            ('t-w864-ix-110', 1),
            ('t-w864-ix-085', 1),
            ('t-w864-ix-072', 1),
            ('t-w864-ix-087', 1),
            ('t-w864-ix-086', 1),
            ('t-w864-ix-128', 1),
            ('t-w864-ix-129', 1),
            ('t-w864-ix-038', 1),
            ('t-w864-ix-043', 1),
            ('t-w864-ix-107', 1),
            ('t-w864-ix-044', 1),
            ('t-w864-ix-102', 1),
            ('t-w864-ix-046', 1),
            ('t-w864-ix-014', 1),
            ('t-w864-ix-060', 1),
            ('t-w864-ix-161', 1),
            ('t-w864-ix-159', 1),
            ('t-w864-ix-099', 1),
            ('t-w864-ix-096', 1),
            ('t-w864-ix-097', 1),
            ('t-w864-ix-050', 1),
            ('t-w864-ix-137', 1),
            ('t-w864-ix-111', 1),
            ('t-w864-ix-015', 1),
            ('t-w864-ix-115', 1),
            ('t-w864-ix-053', 1),
            ('t-w864-ix-118', 1),
            ('t-w864-ix-034', 1),
            ('t-w864-ix-019', 1),
            ('t-w864-ix-037', 1)],
 'times': {'2015-02-22': 2,
           '2015-02-23': 1,
           '2015-02-24': 1,
           '2015-02-25': 3,
           '2015-02-26': 3,
           '2015-03-03': 3,
           '2015-03-05': 3,
           '2015-03-06': 1,
           '2015-03-07': 1,
           '2015-03-08': 2,
           '2015-03-09': 2,
           '2015-03-10': 8,
           '2015-03-11': 2,
           '2015-03-12': 6,
           '2015-03-13': 2,
           '2015-03-14': 2,
           '2015-03-16': 1,
           '2015-03-17': 3,
           '2015-03-18': 3,
           '2015-03-19': 6,
           '2015-03-20': 5,
           '2015-03-21': 6,
           '2015-03-22': 1,
           '2015-03-23': 8,
           '2015-03-24': 5,
           '2015-03-25': 1}}
Flags: needinfo?(jlund)
See Also: → 1147719
I don't think I qualify as a Windows relenger, and I'm not aware of any recent changes that would cause this. Sorry.
Flags: needinfo?(mshal)
(In reply to Jordan Lund (:jlund) from comment #89)
> with logging from patch in comment 43:
> 14:57:31     INFO -  1961 INFO click: toolbarbutton-anchor
> 14:57:31     INFO -  1962 INFO TEST-PASS |
> layout/xul/test/test_bug987230.xul | Popup should only be shown once
> 14:57:31     INFO -  1963 INFO Sending mousedown+up for offsets: 5, 5;
> innerscreen: 24, 376; rect: 0, 33.
> 14:57:31     INFO -  1964 INFO Resulting x, y, scale: 29, 414, 1
> 14:57:31     INFO -  1965 INFO Final params: 29, 414

It's weird that this is the only thing logged, and nothing is happening for the mousemove. It'd tend to point to this click resulting in the other screen showing. I wonder why that'd happen. Is there a way to request an additional screenshot here?


It would be interesting to know what these are for successful runs on the talos machines. Do we have this info or do I need requestCompleteLog magic to make that appear in the logs?

(ni -> Ryan for both of these questions)
Flags: needinfo?(ryanvm)
(In reply to :Gijs Kruitbosch from comment #117)
> (In reply to Jordan Lund (:jlund) from comment #89)
> > with logging from patch in comment 43:
> > 14:57:31     INFO -  1961 INFO click: toolbarbutton-anchor
> > 14:57:31     INFO -  1962 INFO TEST-PASS |
> > layout/xul/test/test_bug987230.xul | Popup should only be shown once
> > 14:57:31     INFO -  1963 INFO Sending mousedown+up for offsets: 5, 5;
> > innerscreen: 24, 376; rect: 0, 33.
> > 14:57:31     INFO -  1964 INFO Resulting x, y, scale: 29, 414, 1
> > 14:57:31     INFO -  1965 INFO Final params: 29, 414
> 
> It's weird that this is the only thing logged, and nothing is happening for
> the mousemove. It'd tend to point to this click resulting in the other
> screen showing. I wonder why that'd happen. Is there a way to request an
> additional screenshot here?

No clue. Ted?

> It would be interesting to know what these are for successful runs on the
> talos machines. Do we have this info or do I need requestCompleteLog magic
> to make that appear in the logs?

I believe that's correct (the latter part).
Flags: needinfo?(ryanvm) → needinfo?(ted)
(In reply to :Gijs Kruitbosch from comment #191)
> remote:   https://hg.mozilla.org/integration/fx-team/rev/8484ed076204

Successful pass:

09:09:50     INFO -  2109 INFO TEST-START | layout/xul/test/test_bug987230.xul
09:09:50     INFO -  ++DOMWINDOW == 107 (0000006738307400) [pid = 2520] [serial = 4311] [outer = 0000006742645C00]
09:09:50     INFO -  2110 INFO click: toolbarbutton-anchor
09:09:50     INFO -  2111 INFO TEST-PASS | layout/xul/test/test_bug987230.xul | Popup should only be shown once
09:09:50     INFO -  2112 INFO Sending mousedown+up for offsets: 5, 5; innerscreen: 24, 376; rect: 0, 33.
09:09:50     INFO -  2113 INFO Resulting x, y, scale: 29, 414, 1
09:09:50     INFO -  2114 INFO Final params: 29, 414
09:09:50     INFO -  2115 INFO TEST-PASS | layout/xul/test/test_bug987230.xul | Popup hidden
09:09:50     INFO -  2116 INFO click: hbox-anchor
09:09:50     INFO -  2117 INFO TEST-PASS | layout/xul/test/test_bug987230.xul | Popup should only be shown once
09:09:50     INFO -  2118 INFO Sending mousedown+up for offsets: 5, 5; innerscreen: 24, 376; rect: 0, 165.
09:09:50     INFO -  2119 INFO Resulting x, y, scale: 29, 546, 1
09:09:50     INFO -  2120 INFO Final params: 29, 546
09:09:50     INFO -  2121 INFO TEST-PASS | layout/xul/test/test_bug987230.xul | Popup hidden
09:09:50     INFO -  2122 INFO Mousemove: 628, 276 (from innerscreen 24, 376 and rect width 504 and scale 1)

Failure:

> (In reply to Jordan Lund (:jlund) from comment #89)
> > with logging from patch in comment 43:
> > 14:57:31     INFO -  1961 INFO click: toolbarbutton-anchor
> > 14:57:31     INFO -  1962 INFO TEST-PASS |
> > layout/xul/test/test_bug987230.xul | Popup should only be shown once
> > 14:57:31     INFO -  1963 INFO Sending mousedown+up for offsets: 5, 5;
> > innerscreen: 24, 376; rect: 0, 33.
> > 14:57:31     INFO -  1964 INFO Resulting x, y, scale: 29, 414, 1
> > 14:57:31     INFO -  1965 INFO Final params: 29, 414

These are the exact same. This means I'm out of ideas. :-\

Unless... is this just some kind of screen saver thing? I didn't think those showed the start screen, though...

> 
> It's weird that this is the only thing logged, and nothing is happening for
> the mousemove. It'd tend to point to this click resulting in the other
> screen showing. I wonder why that'd happen. Is there a way to request an
> additional screenshot here?

Re: screenshots: we'd need to write more harness code to do that.
At this point I think we should just disable this test. I have no idea what's causing the issue. It'd be interesting if disabling the test actually fixed it rather than move it elsewhere... Needinfo to me to do this; if someone else can get to it before me, please do.
Flags: needinfo?(ted)
Flags: needinfo?(gijskruitbosch+bugs)
Flags: needinfo?
Flags: needinfo?
Flags: needinfo?(gijskruitbosch+bugs)
Whiteboard: test disabled
https://hg.mozilla.org/mozilla-central/rev/a1eaa7d45f0c

Of course, this doesn't help with the other test suites that fall victim to the underlying bug :(
(In reply to Ryan VanderMeulen [:RyanVM UTC-4] from comment #228)
> https://hg.mozilla.org/mozilla-central/rev/a1eaa7d45f0c
> 
> Of course, this doesn't help with the other test suites that fall victim to
> the underlying bug :(

Hmmm... so bug 1147719 also uses native event synthesization, and so does test_plugin_focus.html (bug 924728). I can't find anything about the social tests here. However, it's clear that *something* there is going wrong.

kats, you've recently worked on some of this stuff to do with native event synth. Any idea of what's going on here and/or how we could debug it?
Flags: needinfo?(bugmail.mozilla)
Hm, not much to go on here, comment 192 eliminates the main possibilities. One thing I noticed though was that in comment 89 there's a bunch of Browser.Experiments.Experiments	output - is that the case for other failing cases too? If so, is it possible that the browser is popping up some other window in the middle of the test that is eating the mousedown? However that may just be a red herring because I think the INFO lines after are only dumped after the test times out, and so it might have gotten into an error state before the Browser.Experiments thing happened.

I don't really have much more expertise in this area - the main issues I was dealing with were related to drag-and-drop which are more complex because they are managed by the OS - simple mousedown/mouseup events should be handled fine and not hang as far as I know.
Flags: needinfo?(bugmail.mozilla)
did you try to register observers for the two calls to sendNativeMouseEvent and see if they were invoked?
it might also be interesting to put warnings into nsWindow::SynthesizeNativeMouseEvent to check the rv of SetCursorPos and SendInput
(In reply to Kartikaya Gupta (email:kats@mozilla.com) from comment #231)
> Hm, not much to go on here, comment 192 eliminates the main possibilities.
> One thing I noticed though was that in comment 89 there's a bunch of
> Browser.Experiments.Experiments	output - is that the case for other failing
> cases too? If so, is it possible that the browser is popping up some other
> window in the middle of the test that is eating the mousedown? However that
> may just be a red herring because I think the INFO lines after are only
> dumped after the test times out, and so it might have gotten into an error
> state before the Browser.Experiments thing happened.

I believe these lines always show up in hanging logs because they happen on a timeout, and so they show up when we wait around not doing much. Ryan would know better than me. Ryan?

> I don't really have much more expertise in this area - the main issues I was
> dealing with were related to drag-and-drop which are more complex because
> they are managed by the OS - simple mousedown/mouseup events should be
> handled fine and not hang as far as I know.

Hm. I mean, I still suspect that we are somehow ending up clicking the start button in these tests... so it seems like the mouse position is not what we expect it to be. Is there some way to test that hypothesis? Like Marco's suggestion maybe?
Flags: needinfo?(ryanvm)
Flags: needinfo?(bugmail.mozilla)
since I was bored, I did a simple try push with those warnings/observers, at least we can tell if the events went through.
https://treeherder.mozilla.org/#/jobs?repo=try&revision=827d60a07acb
I got a failure, but I didn't see a warning and both observers were invoked. So, the events seem to go through and my test was not useful to figure this failure.
(In reply to :Gijs Kruitbosch from comment #235)
> Hm. I mean, I still suspect that we are somehow ending up clicking the start
> button in these tests... so it seems like the mouse position is not what we
> expect it to be. Is there some way to test that hypothesis? Like Marco's
> suggestion maybe?

The coordinates passed in from JS should go to the widget without any transformations, so if they're the same in the pass/fail cases in JS they should be the same in widget. It might be worth double-checking that by logging the coordinates in the widget code. Might also be worth dumping the widget screen bounds, to see if that's moving around somehow.
Flags: needinfo?(bugmail.mozilla)
(In reply to :Gijs Kruitbosch from comment #235)
> I believe these lines always show up in hanging logs because they happen on
> a timeout, and so they show up when we wait around not doing much. Ryan
> would know better than me. Ryan?

Correct.
Flags: needinfo?(ryanvm)
I did some testing where some logging added to log windows mouse and focus messages. It turns out that on a run when test_bug987230.xul fails, we stop receiving them after test_bug665540.html runs. This test opens a new fullscreen window and opens a <select> popup. Bug 1053783 is suspicious, but was checked in a few weeks before this starting failing.

The other difference from a passing run is that we get WM_KILLFOCUS before WM_ACTIVATE when it fails.

I'll try adding some more logging based on the assumption that this is related to this failure.
I debugged this a bit more. When this fails, we in fact don't get any native mouse messages throughout the entire test run. The mouse cursor is at the same place as a passing run (800, 600).

One notable difference is that shortly after startup, we get WM_ACTIVATEAPP messages differently for passing versus failing runs.

Passing:
<Windows Message: 0000004A962DC800 hwnd: 0000000000030170 msg: 1c wparam: 1 lparam: D94>
<Windows Message: 0000004A93170800 hwnd: 00000000000301F4 msg: 1c wparam: 1 lparam: D94>
<Windows Message: 0000004A962DC800 hwnd: 0000000000030170 msg: 1c wparam: 0 lparam: D94>
<Windows Message: 0000004A93170800 hwnd: 00000000000301F4 msg: 1c wparam: 0 lparam: D94>
...
<Windows Message: 0000004A962DC800 hwnd: 0000000000030170 msg: 1c wparam: 1 lparam: D94>
<Windows Message: 0000004A93170800 hwnd: 00000000000301F4 msg: 1c wparam: 1 lparam: D94>


Failing:
<Windows Message: 000000DA2F838C00 hwnd: 0000000000030194 msg: 1c wparam: 1 lparam: 0>
<Windows Message: 000000DA2B031C00 hwnd: 00000000005D01F4 msg: 1c wparam: 1 lparam: 0>
...
<Windows Message: 000000DA2F838C00 hwnd: 0000000000030194 msg: 1c wparam: 1 lparam: 0>
<Windows Message: 000000DA2B031C00 hwnd: 00000000005D01F4 msg: 1c wparam: 1 lparam: 0>

The passing run gets an application activated message, followed by an application deactivated message (wparam: 0) then a few moments later an application activated message. Later, some tests change the application activated state (such as test_hangui.xul) and we get the right sequence of messages.)

The failing run only ever receives application activated messages (wparam is always 1) and lparam is always 0, but is supposed to indicate the thread of the application being activated/deactivated.

As an aside, when I run locally on Windows 7, I get the same results as the passing run.

So I think here the browser is simply failing to properly get activated when the test run starts. Perhaps the start screen is already open to start with?
Brian, do you have any idea what might be going on here, or can redirect this to someone who might?
Flags: needinfo?(netzen)
Perhaps by disabling the start screen on boot, something like:
http://www.gottabemobile.com/2013/10/06/narrative-clip-wearable-camera-available-nov-1-279/ ?

jimm may have some more ideas.
Flags: needinfo?(netzen)
Depends on: 1169243
Sounds like we're going to try bug 1169243 as a solution.
Flags: needinfo?(q)
Fixed by bug 1169243.
Status: NEW → RESOLVED
Closed: 9 years ago
status-firefox39: --- → fixed
status-firefox40: --- → fixed
status-firefox41: --- → fixed
status-firefox-esr31: --- → fixed
status-firefox-esr38: --- → fixed
Keywords: leave-open, regression
Resolution: --- → FIXED
Whiteboard: test disabled
Target Milestone: --- → mozilla41
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Armen told me he knew someone who had looked into this before.
Flags: needinfo?(armenzg)
Hi Neil, I see that Q has already looked into this in bug 1169243.

For the record, we can place the mouse anywhere we want to for Windows 8 machines.
We have a script that I wrote few years ago that I limited to Windows 7 32-bit machines which can be activated for Windows 8.

Is there anyone from releng that could help with this? I'm gone next week.

The way that this works is that desktop unittests will call mouse_and_screen_resolution.py which reads from hgweb the file machine-configuration.json.
This manifest file indicates both screen resolution and mouse position for the tests and it atomized to push which prevents regressions across the board.

You can create your own mozharness user repo and make changes to mouse_and_screen_resolution.py and when pushing to try you need to adjust mozharness.json from your gecko tree.

At the moment, the machine-configuration.json would be shared by both Windows 7 32-bit jobs and Windows 8 64-bit jobs.
Hopefully you would not need any changes to machine-configuration.json but only to mouse_and_screen_resolution.py

https://hg.mozilla.org/mozilla-central/raw-file/default/testing/machine-configuration.json
http://hg.mozilla.org/build/mozharness/file/default/external_tools/mouse_and_screen_resolution.py#l61

04:50:25     INFO - Running pre test command run mouse & screen adjustment script with 'c:\mozilla-build\python27\python.exe ../scripts/external_tools/mouse_and_screen_resolution.py --configuration-url https://hg.mozilla.org/%(repo_path)s/raw-file/%(revision)s/testing/machine-configuration.json'
04:50:25     INFO - Running command: ['c:\\mozilla-build\\python27\\python.exe', '../scripts/external_tools/mouse_and_screen_resolution.py', '--configuration-url', u'https://hg.mozilla.org/mozilla-central/raw-file/f7e1f596d57d2c112685172a3b708f1cb0eaf93b/testing/machine-configuration.json'] in C:\slave\test\build
04:50:25     INFO - Copy/paste: c:\mozilla-build\python27\python.exe ../scripts/external_tools/mouse_and_screen_resolution.py --configuration-url https://hg.mozilla.org/mozilla-central/raw-file/f7e1f596d57d2c112685172a3b708f1cb0eaf93b/testing/machine-configuration.json
04:50:25     INFO -  INFO: This script was written to be used with Windows 7 32-bit machines.
04:50:25     INFO - Return code: 0
Flags: needinfo?(armenzg)
This problem seems to thinning out has anything changed?
Maybe related to the reduction of comments by the bot:
https://groups.google.com/forum/#!topic/mozilla.dev.platform/CB__7uXq6yI

We will probably get a summary in a week.

Maybe there is a way to inspect occurrences without having to wait for that summary.
That isn't even deployed to production, but he doesn't mean at that narrow a scale anyway - if you look at either https://brasstacks.mozilla.com/orangefactor/?display=Bug&bugid=1135545&entireHistory=true&tree=all or just the frequency of comments here since they're still turned on, we've gone from 21 instances in July and 14 in August to just 5 instances in September.
Would love to know what changed that caused this to spike recently.
Bulk assigning P3 to all open intermittent bugs without a priority set in Firefox components per bug 1298978.
Priority: -- → P3
See Also: → 1336747
See Also: → 1406803
Component: XP Toolkit/Widgets: Menus → XUL
Summary: Intermittent Win8 cascade of failure starting with test_bug987230.xul | Test timed out where the screenshot shows the Start screen → Intermittent Win8 cascade of failure starting with test_bug987230.xhtml,test_bug987230.xul | Test timed out where the screenshot shows the Start screen
Severity: normal → S3

https://wiki.mozilla.org/Bug_Triage#Intermittent_Test_Failure_Cleanup
For more information, please visit BugBot documentation.

Status: REOPENED → RESOLVED
Closed: 9 years ago → 11 months ago
Resolution: --- → INCOMPLETE
You need to log in before you can comment on or make changes to this bug.