Closed Bug 593491 Opened 14 years ago Closed 12 years ago

Intermittent test_hover.html failure | Test timed out., followed by test_bug437844.xul | :hover does not apply - got rgb(0, 255, 0), expected transparent

Categories

(Core :: CSS Parsing and Computation, defect)

x86
All
defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: jdm, Unassigned)

References

Details

(Keywords: intermittent-failure)

Attachments

(2 files)

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1283547439.1283549623.24949.gz WINNT 5.2 mozilla-central debug test mochitest-other on 2010/09/03 13:57:19 s: win32-slave35 7315 ERROR TEST-UNEXPECTED-FAIL | chrome://mochikit/content/chrome/layout/style/test/chrome/test_hover.html | Test timed out. TEST-UNEXPECTED-FAIL | chrome://mochikit/content/browser/browser/components/places/tests/browser/browser_history_sidebar_search.js | Exited with code -2147483645 during test run TEST-UNEXPECTED-FAIL | automationutils.processLeakLog() | missing output line for total leaks!
Bug 493359 comment 11 is also an occurrence of this.
Looks like the document.open() call in the test is failing with NS_ERROR_DOM_SECURITY_ERR. We can get rid of the document.open() call in the test but that doesn't solve whatever is the underlying problem. I moved the test from mochitest-plain to mochitest-chrome yesterday, that probably has something to do with this.
Is this a duplicate of bug 593262?
No, bug 593262 was not intermittent and was fixed (I forgot to mark that). The change bug 593262 probably caused this bug.
Summary: mochitest-plain: intermittent test_hover.html failure | Test timed out. → Intermittent test_hover.html failure | Test timed out.
Attached patch add some debugging output (deleted) — Splinter Review
I plan to land this to see which of the two error paths is being hit in nsHTMLDocument::OpenCommon.
Comment on attachment 473174 [details] [diff] [review] add some debugging output Landed the debugging output patch http://hg.mozilla.org/mozilla-central/rev/1c9f1fe2d459
Bug 493359 comment 13 is another instance of this.
The last four logs says: WARNING: Principals unequal for open call.
Yeah, I need to add some more debugging output to get any further here, I'll do that in the near future.
Comment 15 of bug 493359 is another instance of this.
Attached patch add some more debugging output (deleted) — Splinter Review
If we start seeing this again I would like to land this patch to get some more information.
Important part of the above log nsHTMLDocument::OpenCommon callerDoc chrome://mochitests/content/chrome/layout/style/test/chrome/hover_helper.html this about:blank
Those are the URIs we would expect, but the NodePrincipals aren't equal, so maybe it is the about:blank document that loads before iframe's specified about:blank document. I'll try sticking a barebones data URI into the iframe to see if that is the case.
Relevant part from the last log: 7383 INFO TEST-START | chrome://mochitests/content/chrome/layout/style/test/chrome/test_hover.html ... nsHTMLDocument::OpenCommon callerDoc chrome://mochitests/content/chrome/layout/style/test/chrome/hover_helper.html this about:blank WARNING: NS_ENSURE_SUCCESS(rv, rv) failed with result 0x805303E8: file e:/builds/moz2_slave/tryserver-win32-debug/build/content/html/document/src/nsHTMLDocument.cpp, line 2054 JavaScript error: , line 0: uncaught exception: [Exception... "Security error" code: "1000" nsresult: "0x805303e8 (NS_ERROR_DOM_SECURITY_ERR)" location: "<unknown>"] JavaScript error: chrome://mochikit/content/tests/SimpleTest/EventUtils.js, line 214: aEvent is undefined ... WARNING: An event was posted to a thread that will never run it (rejected): file e:/builds/moz2_slave/tryserver-win32-debug/build/xpcom/threads/nsThread.cpp, line 371 WARNING: leaking reference to nsTimerImpl: file e:/builds/moz2_slave/tryserver-win32-debug/build/xpcom/threads/nsTimerImpl.cpp, line 491 WARNING: 1 sort operation has occurred for the SQL statement '0x50a6da0'. See https://developer.mozilla.org/En/Storage/Warnings details.: file e:/builds/moz2_slave/tryserver-win32-debug/build/storage/src/mozStoragePrivateHelpers.cpp, line 138 NEXT ERROR 7384 ERROR TEST-UNEXPECTED-FAIL | chrome://mochitests/content/chrome/layout/style/test/chrome/test_hover.html | Test timed out.
I checked the try server revision that comment 39 and comment 40 are about and unfortunately they do not include the changeset of comment 38, so the information doesn't tell us anything.
I wonder if making the iframe src a data URI solved this bug inadvertently because we load data URIs synchronously maybe? I seem to remember something about that when the HTML5 parser was turned on by default.
Landed attachment 481768 [details] [diff] [review] http://hg.mozilla.org/mozilla-central/rev/0a29ac059eb5 If I'm right then we'll get some more instances of this.
data: URIs are async with the HTML5 parser. document.close() can be async, too. It's possible that the task posted by document.close() is racing with something else.
Summary: Intermittent test_hover.html failure | Test timed out. → Intermittent test_hover.html failure | Test timed out., followed by test_bug437844.xul | :hover does not apply - got rgb(0, 255, 0), expected transparent
(In reply to TinderboxPushlog Robot from comment #130) > https://tbpl.mozilla.org/php/getParsedLog.php?id=10676108&tree=Firefox > Rev3 WINNT 5.1 mozilla-central debug test mochitest-other on 2012-04-05 > 13:14:37 Screenshot is too late: bug 637101.
Depends on: 637101
OS: Linux → All
Whiteboard: [orange]
Resolving WFM keyword:intermittent-failure bugs last modified >3 months ago, whose whiteboard contains none of: {random,disabled,marked,fuzzy,todo,fails,failing,annotated,time-bomb,leave open} There will inevitably be some false positives; for that (and the bugspam) I apologise. Filter on orangewfm.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: