https://treeherder.mozilla.org/logviewer.html#?job_id=88117543&repo=autoland 22:39:54 INFO - 95 INFO TEST-START | browser/components/downloads/test/browser/browser_downloads_panel_block.js 22:40:39 INFO - TEST-INFO | started process screenshot 22:40:39 INFO - TEST-INFO | screenshot: exit 0 22:40:39 INFO - Buffered messages logged at 22:39:54 22:40:39 INFO - 96 INFO Entering test bound mainTest 22:40:39 INFO - Buffered messages logged at 22:39:56 22:40:39 INFO - 97 INFO TEST-PASS | browser/components/downloads/test/browser/browser_downloads_panel_block.js | "PotentiallyUnwanted" == true - 22:40:39 INFO - Buffered messages logged at 22:40:01 22:40:39 INFO - 98 INFO TEST-PASS | browser/components/downloads/test/browser/browser_downloads_panel_block.js | true == true - 22:40:39 INFO - Buffered messages logged at 22:40:03 22:40:39 INFO - 99 INFO TEST-PASS | browser/components/downloads/test/browser/browser_downloads_panel_block.js | "Malware" == true - 22:40:39 INFO - Buffered messages logged at 22:40:08 22:40:39 INFO - 100 INFO TEST-PASS | browser/components/downloads/test/browser/browser_downloads_panel_block.js | true == true - 22:40:39 INFO - Buffered messages logged at 22:40:10 22:40:39 INFO - 101 INFO TEST-PASS | browser/components/downloads/test/browser/browser_downloads_panel_block.js | "Uncommon" == true - 22:40:39 INFO - Buffered messages finished 22:40:39 ERROR - 102 INFO TEST-UNEXPECTED-FAIL | browser/components/downloads/test/browser/browser_downloads_panel_block.js | Test timed out -

This is becoming permorange on Win7 VM Opt with bug 1320994: https://treeherder.mozilla.org/#/jobs?repo=try&revision=35cd1fe45a182eca08d83224545625aa1a0427e7 Paolo, do you want to take a look?

I don't see a relationship between the bug descriptions off the top of my head. There is definitely some code in the test that stands out: https://dxr.mozilla.org/mozilla-central/source/browser/components/downloads/test/browser/browser_downloads_panel_block.js#154-166 A hypothesis is that a subview sliding animation is still occurring when we continue, so the buttons may still be hidden when we try to simulate the clicks. A partial fix might be to simply increase the time in the setTimeout there, but the correct one would be to wait until the animation ends. Alternatively, it might be a case of a failure not related to the specific test, for example the test suite timing out.

I was thrown off for a while thinking this didn't occur anymore (see bug 1320994 comment 55), but that was wrong. Still permorange. Paolo, this is blocking me from landing bug 1320994 and I don't see a relationship to my changes, nor do I know this code well enough to fix it myself. Can you fix this or find someone else who can? Thanks!

(In reply to :Paolo Amadini from comment #2) > A hypothesis is that a subview sliding animation is still occurring when we > continue, so the buttons may still be hidden when we try to simulate the > clicks. A partial fix might be to simply increase the time in the setTimeout > there, but the correct one would be to wait until the animation ends. Could we disable the animation when running tests?

I pushed these for testing timeouts: https://treeherder.mozilla.org/#/jobs?repo=try&revision=a14d885064e95a3c234906c3a157432c370f4c78 https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ac54b0bc39d84b7e8c9c10c7e90e578e6825884

(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #5) > I pushed these for testing timeouts: > https://treeherder.mozilla.org/#/jobs?repo=try&revision=a14d885064e95a3c234906c3a157432c370f4c78 > https://treeherder.mozilla.org/#/jobs?repo=try&revision=3ac54b0bc39d84b7e8c9c10c7e90e578e6825884 No go. And all 4 failures happened at the same place.

Bug 1359655 is also seeing this as permaorange with our patch. I ran https://treeherder.mozilla.org/#/jobs?repo=try&revision=bde6ceb8d93511426afcf21ceceba0fcfa33a62c to confirm it wasn't a one-time intermittent.

(In reply to :Paolo Amadini from comment #2) > A hypothesis is that a subview sliding animation is still occurring when we > continue, so the buttons may still be hidden when we try to simulate the > clicks. A partial fix might be to simply increase the time in the setTimeout > there, but the correct one would be to wait until the animation ends. I increased the timeout to 2 seconds with the SHIELD patch and ran https://treeherder.mozilla.org/#/jobs?repo=try&revision=fb1f69918db5897f7ccc84cf5eb520853ec2ccb9&selectedJob=95764197, which didn't seem to help.

I'm really looking forward to hearing what is actually causing this permaorange, but not while it blocks other patches. browser-chrome is a weird suite, in that only it and devtools do "chunk-by-runtime" where they attempt to make each chunk take approximately the same amount of time, changing the contents of each chunk every time anyone adds or removes as few as just one b-c test. I overdid things with 10, not wanting to work my way up, but https://treeherder.mozilla.org/#/jobs?repo=try&revision=7c7790c1132e0451ec5ea830d1633af4fe832c9b&filter-tier=1 has this test failing because I added 10 tests to shield-recipe which do absolutely nothing, only a single is(true,"") to keep the harness from complaining that they do nothing. So, despite the fact that browser-chrome also does run-by-dir, which means this test is running immediately after the same two downloads tests it always runs after, in a freshly restarted browser with a fresh profile before those two tests ran, it fails when adding unrelated tests which do nothing and which don't even run in the same chunk as it, but cause it to be moved from happily running after we run browser/components/preferences/in-content-old/tests/ and browser/base/content/test/popups/ and browser/base/content/test/static/ and browser/base/content/test/tabcrashed/ to failing to run after we run browser/base/content/test/appUpdate and browser/base/content/test/general and browser/base/content/test/tabcrashed. While I'm going to be fascinated to hear whether it was somehow depending on something left behind outside of the profile by a prefs test or a popup test or all_files_referenced, or is failing because it doesn't like something left behind outside of the profile by appUpdate or general, it can't keep blocking other things from landing just because there's only one browser-chrome chunk where it is able to run, so I'm disabling it (and really really hoping that neither of the two tests after it are going to take up the mantle of failing when they have to move chunks).

Pushed by philringnalda@gmail.com: https://hg.mozilla.org/integration/autoland/rev/195eab9d24cc disable browser_downloads_panel_block.js for failing every time that adding unrelated tests causes it to move into a different chunk

We'll have to take a look at some point, but for the moment we can keep this disabled.