58 bytes, text/x-review-board-request
Inspector bug triage (filter on CLIMBING SHOES)
Priority: -- → P3
Inspector bug triage (filter on CLIMBING SHOES).
Priority: P3 → P2
:pbro, this bug really spiked on November 14th (maybe the 13th based on how you read the data and comment dates)- can you take a look at this? It is one of the top issues remaining on the trees. this is 97% on linux32 (the win7 stuff could be mis filed) and it is a timeout- I am not sure if we get a lot of value out of devtools on linux32, so possibly a disabling is easier than a longer investigation.
(In reply to Joel Maher ( :jmaher) from comment #14) > :pbro, this bug really spiked on November 14th (maybe the 13th based on how > you read the data and comment dates)- can you take a look at this? It is one > of the top issues remaining on the trees. > > this is 97% on linux32 (the win7 stuff could be mis filed) and it is a > timeout- I am not sure if we get a lot of value out of devtools on linux32, > so possibly a disabling is easier than a longer investigation. Thanks Joel. This one is another case of a test that passes but started to take a few more seconds than the allowed threshold recently, for some obscure reasons. You're right that we could disable it (or maybe just increase the timeout), but looking at the test, it seems to be one that can be very easily split up in several parts. It seems to be really long and composed of fairly independent parts. So I'd like us to do this instead. If after this, some parts keep on running for too long, we can then start disabling on linux debug 32 as suggested. Alex: do you have some time to look into this simple test splitting bug? r=test-only would be fine for something like this.
Flags: needinfo?(pbrosset) → needinfo?(poirot.alex)
Priority: P2 → P1
Do we ever had a linux32-only bug to fix? Or may be it helped us fix some real world races? If not, is there value in running linux32 devtools at all? This test is all about increments, if we split it, it would be quite arbitrary of split in many this time very small piece. I would be more in favor of incresing the timeout while looking at possible performance tweaks. What is this timeout? 30s? It runs in 10s locally. Also, the rule view throws some errors to the console. This is related to: (from bug 1069829): https://hg.mozilla.org/mozilla-central/rev/99fbe8621fa7 I imagine it can slow the test down. This test runs 20-30% faster by reverting that. But that's not what recently regressed as it landed long time ago.
https://hg.mozilla.org/integration/mozilla-inbound/rev/b2a7cf1f8f467495d0a3d1f06935ee76d147b466 Bug 1275446 - Bump timeout threshold for browser_rules_edit-property-increments.js on linux32. r=test-only
(In reply to Alexandre Poirot [:ochameau] from comment #18) > > What is this timeout? 30s? It runs in 10s locally. The timeout is 45 seconds (http://searchfox.org/mozilla-central/rev/b4e6fa3527436bdbcd9dd2e1982382fe423431f3/testing/mochitest/browser-test.js#3)
Status: ASSIGNED → RESOLVED
Last Resolved: 2 years ago
status-firefox53: --- → fixed
Resolution: --- → FIXED
Target Milestone: --- → Firefox 53
status-firefox51: --- → unaffected
status-firefox52: --- → affected
status-firefox52: affected → fixed
You need to log in before you can comment on or make changes to this bug.