TEST-PASS | ../../../_tests/xpcshell-simple/test_uriloader_exthandler/unit/test_handlerService.js | all tests passed TEST-UNEXPECTED-FAIL | ../../../_tests/xpcshell-simple/test_uriloader_exthandler/unit/test_punycodeURIs.js | test failed, see log ../../../_tests/xpcshell-simple/test_uriloader_exthandler/unit/test_punycodeURIs.js.log: >>>>>>> *** HandlerServiceTest: getFile: requesting UMimTyp *** test pending [Exception... "Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsILocalHandlerApp.launchWithURI]" nsresult: "0x80004005 (NS_ERROR_FAILURE)" location: "JS frame :: ../../../_tests/xpcshell-simple/test_uriloader_exthandler/unit/test_punycodeURIs.js :: run_test :: line 129" data: no] *** FAIL *** <<<<<<< NEXT ERROR gmake[4]: *** [check] Error 1 I can't reproduce on Mac OS X 10.5, neither can Firefox. This only seems to occur on SeaMonkey tinderbox with Mac OS X 10.4

Mnyromyr says (over irc) this fails on 10.4 SM

nsLocalHandlerAppMac::LaunchWithURI is calling ::LSOpenFromURLSpec, which fails with err=-10822 ("kLSServerCommunicationErr: There is a problem communicating with the server process that maintains the Launch Services database."), which results in NS_ERROR_FAILURE...

Josh, any idea what might be the problem here, especially with SM vs. FF, 10.4 vs. 10.5?

Offhand, I'd try nuking the LaunchServices database on that tinderbox and forcing it to rebuild itself.

Well, I see the problem on my PowerBook G4, and neither recreating the LaunchServices database nor registering the SeaMonkey.app does help. :-(

Fwiw, this exception "just" appeared on Thunderbird "MacOSX 10.4 comm-central check" too: understanding why, then fixing it, may help fix SeaMonkey box too...

(What the hell: bmo lag, then mid-air with myself, now a wrong flag :-/)

Fwiw: (for Thunderbird only) {{ 9dae4af4b459: Disable test_punycodeURIs.js on mac only, part of bug 450884. Mark Banner <bugzilla@standard8.plus.com> - Wed, 20 Aug 2008 19:04:48 +0100 - rev 151 }}

(In reply to comment #8) > Fwiw: (for Thunderbird only) Note: With that fix, MacOSX TB TUnit jumped from "233/1" to "327/0". MacOSX SM is at "234/1", while Linux and Windows are at 303-304/0. It looks like the failure of that test is preventing other tests to be run :-( Could that be looked into and fixed too ? (Probably in another bug.)

(In reply to comment #9) > (Probably in another bug.) I filed bug 451474.

This is the last permanently-failing test left on that box, I guess we can mask over it with an override similar to Thunderbird, or is a fix in sight? Mark, what should we go for?

(In reply to comment #11) > This is the last permanently-failing test left on that box, I guess we can mask > over it with an override similar to Thunderbird, or is a fix in sight? > Mark, what should we go for? From the discussions I've had this seems to be a 10.4 specific bug (probably) that some people are seeing. I've certainly got no way of debugging or fixing it. So I'd suggest just disabling it in the same way as TB.

I have no idea how to run these tests, so I don't know if this works. But it should, theoretically :)

Just for reference, if there would be a Makefile list of tests, I'd have wrapped it in a ifneq (Darwin8,$(OS_TARGET)$(basename $(OS_RELEASE)))

Comment on attachment 338309 [details] [diff] [review] change the test to not run on 10.4 Maybe turn your comment into a warning dump().

As any OS+version detection in xpcshell seems not to be available right now, I'm copying the hacky approach used by Thunderbird right now and trying to make Tiger-specific exclusion based on this here. I haven't tested it yet, will do so on a test cycle of the SeaMonkey box as soon as my time allows (tight this weekend) but anyone else on 10.4 should be able to test his.

Does this do what you want? const httpHandler = Components.classes["@mozilla.org/network/protocol;1?name=http"] .getService(Components.interfaces.nsIHttpProtocolHandler); const oscpu = httpHandler.oscpu; if (oscpu.match(/Mac OS X 10.4/)) // skip this test ?

(In reply to comment #17) > Does this do what you want? (That's the kind of code I had in mind when I wrote about dbaron/httpd.js iirc ... but I could not find the bug/code where it happened. Thanks Boris.)

(In reply to comment #18) > ... but I could not find the bug/code where it happened. Ah, got it: see patch in bug 448121 ! :-)

Thanks Boris, that works!

Comment on attachment 338318 [details] [diff] [review] hacky disabling of the test on Tiger (Darwin 8) Ugh, I *really* don't like this. :-( No traction on figuring this out yet? Honestly, I'd rather disable the test completely than resort to this.

(In reply to comment #21) > (From update of attachment 338318 [details] [diff] [review]) > Ugh, I *really* don't like this. :-( No traction on figuring this out yet? > Honestly, I'd rather disable the test completely than resort to this. This seems to be a 10.4 only issue. FF doesn't have any 10.4 boxes, from what I've heard via Karsten, some people have tried it on 10.4 but haven't seen it.

I also don't like this, but it seems nobody has the cycles to figure out why/how it fails on 10.4 (Karsten saw it fail on his 10.4 system as well, IIRC). I don't think it makes sense to disable the test where it runs, as when it fails it doesn't even come as far as to test the actual functionality, and where it runs, we actually can test that functionality, which is good. The JS fix sounds better than the hacky build system fix though, I just wait that _one_ of them gets review as my main focus for now is to finally gets green unit test boxes so we actually notice new failures by getting new orange.

Yes, the test fails for me. My main question would be, why the test passes stuff through nsLocalHandlerAppMac::LaunchWithURI at all, as this doesn't seem to be the actual scope of the test?

(In reply to comment #24) > Yes, the test fails for me. > My main question would be, why the test passes stuff through > nsLocalHandlerAppMac::LaunchWithURI at all, as this doesn't seem to be the > actual scope of the test? Errm, localHandler.launchWithURI(uri) is the main point of the test - we need to call an external app with a URI and check that we have pass it an ascii uri (rather than an idn one). I would therefore naturally assume the function would go through the mac-specific handler nsLocalHandlerAppMac::LaunchWithURI. How else would this be tested?

(In reply to comment #25) > Errm, localHandler.launchWithURI(uri) is the main point of the test - we need > to call an external app with a URI and check that we have pass it an ascii uri > (rather than an idn one). Oh, misunderstanding on my side, then. My apologies.

Comment on attachment 338318 [details] [diff] [review] hacky disabling of the test on Tiger (Darwin 8) I'm sorry, I want to see green trees too, but I just can't r+ a hack this awful. I would support disabling this test entirely until the root cause is fixed.

Comment on attachment 338323 [details] [diff] [review] bz's comment as a patch [Checkin: Comment 31] Well the test works, but given its in m-c, and I'm not a peer anywhere near there, I'm not sure I can grant review for this. Maybe try Benjamin/ted? There should also be a bug filed in core covering the fact that this test fails on Mac 10.4. Giving the error mentioned in comment 0 that the launchWithURI call fails.

Comment on attachment 338323 [details] [diff] [review] bz's comment as a patch [Checkin: Comment 31] Mark: Hrm, denying to review this on a test you wrote yourself is not helpful. :( Trying randomly to get someone else to review it. Ted, you up to it? Filing a followup is a good idea in any case, but I'm slowly but surely getting really mad on this issue, it's uselessly costing me more time than some actually really hard problems.

Comment on attachment 338323 [details] [diff] [review] bz's comment as a patch [Checkin: Comment 31] This still sucks, but having your test box be perma-orange isn't helping anything. I'd really like to get some eyes on this and figure out what's broken.

I fully agree with every word in your statement, Ted. Pushed the patch as http://hg.mozilla.org/mozilla-central/rev/269af1ed7564 and filed bug 456606 for fixing/investigating the real issue.

http://tinderbox.mozilla.org/showlog.cgi?log=SeaMonkey/1222198519.1222203403.18916.gz MacOSX 10.4 comm-central dep unit test on 2008/09/23 12:35:19 is GREEN :-) At last !