https://tbpl.mozilla.org/php/getParsedLog.php?id=15983272&tree=Mozilla-Inbound Rev4 MacOSX Snow Leopard 10.6 mozilla-inbound opt test mochitest-other on 2012-10-10 04:43:23 PDT for push 8fa702386c7c slave: talos-r4-snow-039 TEST-PASS | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_782653_CSS_links_in_Style_Editor.js | Correct Style Sheet is selected in the editor TEST-INFO | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_782653_CSS_links_in_Style_Editor.js | Console message: [JavaScript Warning: "XUL box for a element contained an inline #text child, forcing all its children to be wrapped in a block." {file: "chrome://browser/content/styleeditor.xul" line: 0}] TEST-INFO | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_782653_CSS_links_in_Style_Editor.js | Console message: [JavaScript Warning: "XUL box for h3 element contained an inline #text child, forcing all its children to be wrapped in a block." {file: "chrome://browser/content/styleeditor.xul" line: 0}] TEST-INFO | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_782653_CSS_links_in_Style_Editor.js | Console message: [JavaScript Warning: "XUL box for h3 element contained an inline #text child, forcing all its children to be wrapped in a block." {file: "chrome://browser/content/styleeditor.xul" line: 0}] TEST-INFO | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_782653_CSS_links_in_Style_Editor.js | Console message: [JavaScript Warning: "Use of Mutation Events is deprecated. Use MutationObserver instead." {file: "chrome://browser/content/orion.js" line: 3408}] TEST-INFO | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_782653_CSS_links_in_Style_Editor.js | Console message: [JavaScript Warning: "Use of Mutation Events is deprecated. Use MutationObserver instead." {file: "chrome://browser/content/orion.js" line: 3408}] TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_782653_CSS_links_in_Style_Editor.js | Test timed out (screenshot) INFO TEST-END | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_782653_CSS_links_in_Style_Editor.js | finished in 30078ms TEST-INFO | checking window state TEST-UNEXPECTED-FAIL | chrome://mochitests/content/browser/browser/devtools/webconsole/test/browser_webconsole_bug_782653_CSS_links_in_Style_Editor.js | Found a Tools:StyleEditor after previous test timed out

https://tbpl.mozilla.org/php/getParsedLog.php?id=15990147&tree=Mozilla-Inbound Rev3 WINNT 5.1 mozilla-inbound opt test mochitest-other on 2012-10-10 10:21:21 PDT for push c0a7e188cc3e slave: talos-r3-xp-067

https://tbpl.mozilla.org/php/getParsedLog.php?id=15990465&tree=Mozilla-Inbound Rev4 MacOSX Lion 10.7 mozilla-inbound opt test mochitest-other on 2012-10-10 10:39:23 PDT for push c0a7e188cc3e slave: talos-r4-lion-005

https://tbpl.mozilla.org/php/getParsedLog.php?id=15997191&tree=Mozilla-Inbound Rev3 WINNT 5.1 mozilla-inbound opt test mochitest-other on 2012-10-10 14:23:06 PDT for push 7d629baabca7 slave: talos-r3-xp-066

https://tbpl.mozilla.org/php/getParsedLog.php?id=16001016&tree=Mozilla-Inbound Rev3 WINNT 6.1 mozilla-inbound opt test mochitest-other on 2012-10-10 17:39:07 PDT for push 315e66e6b2ae slave: talos-r3-w7-042

Only optimized builds, but pretty common so far...

Its very frustrating to not see these happening when you try yourself. I pushed another try with only oths, and more logging near the area where the test starts to time out. No failure until now. https://tbpl.mozilla.org/?tree=Try&rev=6496115281fb And also, the only time the same failure I saw, was in OSX 10.7 debug build, which obv. is not heppening again ever... May be we should push these extra loggings into m-c so that another time the test fails, I know exactly where it fails. @Panos, any thoughts ?

Sure, attach your patch and I'll r+ it. You could also use the following try configuration to further limit the tests to the problematic cases: try: -b o -p linux,linux64,macosx64,win32 -u mochitest-o -t none

Added more logging. I am also doing debug builds as I myself saw this once in debug too. Keep open.

I really don't exactly know if it will work or not, as I personally never experienced this orange front hand. I have added a little more logging, and added an execute soon. I think its a race condition of sync vs async codes. When I first do if (aEditor.sourceEditor) { the source-editor is not loaded so it does not go inside the if, and just after the if block, there is a statement to add a listener for editor loading. But I think until the code execution reaches that line, source-editor loads up.

Comment on attachment 671214 [details] [diff] [review] Possible Fix Mihai knows more about both the Web Console and Style Editor code bases, so you'll have a better chance of getting useful feedback from him.

Comment on attachment 671214 [details] [diff] [review] Possible Fix Girish: thanks for your patch! This patch is fine, keep these changes, but... I looked into the most recent failure and the screenshot. The Style Editor window seems to be covered by a dialog. How about you add a waitForFocus() after you wait for the load event for the style editor window? waitForFocus() will try to focus the style editor window, then the source editor and the style editor can probably fire the right events. I fear executeSoon() won't fixing this. Also, I suggest turning the logging messages into info("foo") calls, instead of ok(true/false, "foo"). Thanks!

@Mihai, I agree that my patch won't fix the solution, its still a test patch. I will keep your watForFocus() call advice in mind, but the Style Editor appears to be behind another window as the test times out and the screenshot is taken after the test times out, thus the next test has already started, which is the reason for Style Editor behind some window. I have also seen a picture where the style editor is focused. Since this bug is not a very common orange, I still wonder on its cause :( Anyways, after this patch lands and I get some more failures, I will try out waitForFocus approach

Really sorry for the delay. I added waitForFocus and changed the test accordingly. Will cleanup and remove extra logging if things look good for a few days. try run at : https://tbpl.mozilla.org/?tree=Try&rev=6765f0fc9fd1

FWIW, the patch Optimizer submitted takes care of the perma-oranges induced by bug 715376 on this test, which is generally a good sign.

Comment on attachment 673767 [details] [diff] [review] test layout change due to waitforfocus Review of attachment 673767 [details] [diff] [review]: ----------------------------------------------------------------- Looks fine. Girish, thanks for the update!

Hopefully fixed in fx-team: https://hg.mozilla.org/integration/fx-team/rev/faa86d5b7b56

Looks like this is still happening post-faa86d5b7b56

I could not push to try, it gets stuck at the checking files stage. Please push it to try someone :)

Pushed : https://tbpl.mozilla.org/?tree=Try&rev=51311531e791

Comment on attachment 677737 [details] [diff] [review] Cleaned up patch with polled checking Thank you Girish! Landed: https://hg.mozilla.org/integration/mozilla-inbound/rev/0574e555e545