This might be a dupe of bug 487915 but that bug seems to be due to something SeaMonkey specific so I am filing a new bug OS X 10.5.2 mozilla-central unit test on 2009/05/21 14:49:26 http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1242942566.1242945640.13326.gz&fulltext=1 *** 78546 INFO Running /tests/security/ssl/mixedcontent/test_bug383369.html... command timed out: 300 seconds without output, killing pid 57514 process killed by signal 9 program finished with exit code -1

Just hit this on the try server: http://tinderbox.mozilla.org/showlog.cgi?log=MozillaTry/1250875861.1250883883.6741.gz Linux try hg unit test on 2009/08/21 10:31:01 (testing patches from bug 113577 on top of mozilla-central's 59d5fa4eac96).

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5-Unittest/1251634342.1251636952.21272.gz WINNT 5.2 mozilla-1.9.1 test mochitests on 2009/08/30 05:12:22 { Running /tests/security/ssl/mixedcontent/test_bug383369.html... TEST-PASS | ... | still secure after back/forward, expected secure got secure TEST-PASS | ... | for 'secure' expected flags [0,0,0], still secure after back/forward TEST-UNEXPECTED-FAIL | ... | Test timed out. } *** While there, ", expected secure got secure" is unexpected, is it not? (same with "all" mixedcontent tests...) mixedContentTest.js has its own ok()/is()/todo(): not sure why it can't rely on the SimpleTest ones...

(In reply to comment #2) Same on Linux: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5-Unittest/1251635839.1251638112.1093.gz Linux mozilla-1.9.1 test mochitests on 2009/08/30 05:37:19

http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1251632770.1251637574.28044.gz WINNT 5.2 mozilla-1.9.1 unit test on 2009/08/30 04:46:10 { Running /tests/security/ssl/mixedcontent/test_bug383369.html... TEST-PASS | ... | still secure after back/forward, expected secure got secure TEST-PASS | ... | for 'secure' expected flags [0,0,0], still secure after back/forward command timed out: 300 seconds without output }

(In reply to comment #4) Same on Linux: http://tinderbox.mozilla.org/showlog.cgi?log=Firefox3.5/1251632770.1251639232.13508.gz Linux mozilla-1.9.1 unit test on 2009/08/30 04:46:10 **** Ah, these 4 comments about Firefox 3.5 seem to be a regression from bug 512759...

(In reply to comment #5) > Ah, these 4 comments about Firefox 3.5 seem to be a regression from bug > 512759... This is _very_ strange, as the same modification seems to work fine on trunk.

I tried a half-backout to try and see if we can fix SeaMonkey and FF 3.5 at the same time. I'm still completely in the dark about what's the cause.

(In reply to comment #5) > Ah, these 4 comments about Firefox 3.5 seem to be a regression from bug > 512759... Ftr, MacOSX too.

Isn't this clearly a dup of bug 512759? It is FF3.5 specific and has the same symptoms.

(In reply to comment #2) > While there, ", expected secure got secure" is unexpected, is it not? > (same with "all" mixedcontent tests...) I use the message as an "OK" message, it makes IMHO much more sense then filling it with an error message: better to see "PASSED OK: We correctly did the test" then "PASSED OK: We failed the test" -> "Why it tells me 'passed ok' when the message tells me there has been as error??? I'm confused!!!" > > mixedContentTest.js has its own ok()/is()/todo(): > not sure why it can't rely on the SimpleTest ones... I have to open a new window for the test body to have its own instance of the security UI. Then I have to postMessage the results to the original window with a different origin, that's what my own todo/is/isnot do.