bugzilla.mozilla.org will be intermittently unavailable on Saturday, March 24th, from 16:00 until 20:00 UTC.
This test seems to be failing consistently on linux: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242232957.1242236034.2073.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242233871.1242239737.9176.gz http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242227885.1242235196.710.gz It started happening after 5a70e386a50c which doesn't make very much sense.
Looks like it happened before too (da613c9fae8c): http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242208481.1242215875.29624.gz
It's happening almost all the time. http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242256987.1242264121.16712.gz Linux mozilla-central unit test on 2009/05/13 16:23:07 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242256475.1242262017.14201.gz Linux mozilla-central unit test on 2009/05/13 16:14:35 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242255008.1242259088.10535.gz#err3 Linux mozilla-central unit test on 2009/05/13 15:50:08
Naturally I can't reproduce it in my Linux VM, even so :-(
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242303436.1242308748.16754.gz Linux mozilla-central unit test on 2009/05/14 05:17:16
OS: Mac OS X → Linux
I believe this showed up with changeset 397dee5a493a
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242310957.1242318558.4118.gz Linux mozilla-central unit test on 2009/05/14 07:22:37
Linux mozilla-central unit test on 2009/05/15 03:44:09 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242384249.1242391345.31240.gz
Roc - Can we disable this test while we debug? It's awfully noisy. Or do we need access to a machine to understand what's failing?
I suppose we could disable it.
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242429504.1242437873.28857.gz Linux mozilla-central unit test on 2009/05/15 16:18:24
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242432224.1242436009.25941.gz Linux mozilla-central unit test on 2009/05/15 17:03:44
I disabled this test, fails too often. http://hg.mozilla.org/mozilla-central/rev/b7bbafb114e2
This was disabled today due to numerous failures on 1.9.1. http://hg.mozilla.org/releases/mozilla-1.9.1/rev/be346d384ff1
So I think we should reenable this, but add a URI test in addition to the title. If/when it fails, it'll at least tell us whether we're even dealing with the right document, right? The most likely thing going on here, imo, is that we're getting some random load event from _somewhere_. Could that be happening? If so, can we adjust the test to detect multiple loads for the same contentDocument and also error on that so we'll see whether that happens?
I can't see how that would happen, but that sounds like a reasonable thing to do.
See, I spent a bit of time reading this code, and I don't see how this bug could happen at all... Hence the question. We've eliminated all the possible things. ;)
Summary: TEST-UNEXPECTED-FAIL | test_videoDocumentTitle.html | Doc title incorrect - got "320x240.ogv", expected "bug461281.ogg" → [test disabled] TEST-UNEXPECTED-FAIL | test_videoDocumentTitle.html | Doc title incorrect - got "320x240.ogv", expected "bug461281.ogg"
Created attachment 525686 [details] [diff] [review] Add more checks to test Boris, reading what you wrote in comment 18, would these changes do what you want? If I've misunderstood, let me know and I'll fix. I also can't reproduce this.
Attachment #525686 - Flags: review?(bzbarsky)
The gDocuments thing is probably a good addition, but I'm not quite sure why comparing window.locations to cwl makes sense, and it's not really what I was after in comment 18. I was thinking something along the lines of assigning the expected URI whenever we assign |title| and then testing the actual URI against it. Also, we'll need to actually reenable the test.
Comment on attachment 525686 [details] [diff] [review] Add more checks to test Per comment 22.
Attachment #525686 - Flags: review?(bzbarsky) → review-
Whiteboard: [test disabled] [orange] → [test disabled]
Runs without issue now. Re-enabled.
Status: NEW → RESOLVED
Last Resolved: 4 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.