Closed Bug 916763 Opened 11 years ago Closed 10 years ago

Intermittent markupview/test/browser_bug896181_css_mixed_completion_new_attribute.js | Popup is open for state 10

Categories

(DevTools :: General, defect)

25 Branch
x86
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED WONTFIX

People

(Reporter: cbook, Assigned: Optimizer)

References

()

Details

Rev4 MacOSX Snow Leopard 10.6 fx-team opt test mochitest-browser-chrome on 2013-09-16 04:43:59 PDT for push 7b5b8819ac56

slave: talos-r4-snow-073

https://tbpl.mozilla.org/php/getParsedLog.php?id=27924377&tree=Fx-Team

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/markupview/test/browser_bug896181_css_mixed_completion_new_attribute.js | Popup is open for state 10


TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/markupview/test/browser_bug896181_css_mixed_completion_new_attribute.js | Test timed out

TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/markupview/test/browser_bug896181_css_mixed_completion_new_attribute.js | Found a tab after previous test timed out: http://mochi.test:8888/browser/browser/devtools/markupview/test/browser_inspector_markup_edit.html
Depends on: 896181
Do you have any ideas about this? :-)
Blocks: 896181
No longer depends on: 896181
Flags: needinfo?(scrapmachines)
Summary: Intermittent TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/markupview/test/browser_bug896181_css_mixed_completion_new_attribute.js | Popup is open for state 10 → Intermittent markupview/test/browser_bug896181_css_mixed_completion_new_attribute.js | Popup is open for state 10
I have no idea :( . But it seems to be related to panel not opening up correctly. I am planning to convert the panel to HTML. lets see if that helps.
Flags: needinfo?(scrapmachines)
Girish, is there a bug on file for comment 51 that we can mark as blocking this one? This is a top orange on both trunk and aurora.
Assignee: nobody → scrapmachines
Flags: needinfo?(scrapmachines)
I am going to cover the conversion in bug 900415 . But the thing that hurts the most is that I went through 4 trys, all heavily retriggerred and I did not get a single failure. What is the point of having try servers and do try runs if they are not going to simulate the actual environment and give the same reliability on intermittents ?
Flags: needinfo?(scrapmachines)
Was that with your patch or vanilla m-c?
With my patch, before landing it. If there had been a single failure, I would not have landed it. I was actually desperately looking for a failure, because I know that playing wiht XUL panels and keypresses in the test is a risky thing.
(In reply to Girish Sharma [:Optimizer] from comment #66)
> I am going to cover the conversion in bug 900415 . But the thing that hurts
> the most is that I went through 4 trys, all heavily retriggerred and I did
> not get a single failure. What is the point of having try servers and do try
> runs if they are not going to simulate the actual environment and give the
> same reliability on intermittents ?

I think the problem is more that even a 1% intermittent failure rate still shows up a lot in automation due to the sheer volume of jobs run [1][2], but your Try runs would struggle to show such a low rate.

[1] http://oduinn.com/blog/2013/09/02/infrastructure-load-for-august-2013/
[2] http://oduinn.com/blog/2013/09/17/6674-builds-and-66456-test-jobs-in-a-24-hour-day/
Test disabled for now for too many intermittent failures:
https://hg.mozilla.org/integration/mozilla-inbound/rev/c49e96acd36c
Whiteboard: [test disabled][leave open]
The test is enabled again as browser_markupview_css_completion_style_attribute.js and is firing just fine now.

Closing this bug as wontfix.
Status: NEW → RESOLVED
Closed: 10 years ago
Resolution: --- → WONTFIX
Whiteboard: [test disabled][leave open]
Product: Firefox → DevTools
You need to log in before you can comment on or make changes to this bug.