447999 - test_punycodeURIs.js fails on (SeaMonkey and Thunderbird) Mac 10.4 tinderbox

Status: RESOLVED FIXED

(SeaMonkey :: General, defect)

Description

[Mark Banner (:standard8)]

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

Comment 1

[Mark Banner (:standard8)]

Mnyromyr says (over irc) this fails on 10.4 SM

Comment 2

[Karsten Düsterloh]

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...

Comment 3

[Karsten Düsterloh]

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

Comment 4

[Chris Lawson (gone)]

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

Comment 5

[Karsten Düsterloh]

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

Comment 6

[Serge Gautherie (:sgautherie)]

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...

Comment 7

[Serge Gautherie (:sgautherie)]

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

Comment 8

[Serge Gautherie (:sgautherie)]

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

Comment 9

[Serge Gautherie (:sgautherie)]

(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.)

Comment 10

[Serge Gautherie (:sgautherie)]

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

I filed bug 451474.

Comment 11

[Robert Kaiser]

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?

Comment 12

[Mark Banner (:standard8)]

(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.

Comment 13

[Markus Stange [:mstange]]

Attachment: change the test to not run on 10.4

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

Comment 14

[Robert Kaiser]

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 15

[Serge Gautherie (:sgautherie)]

Comment on attachment 338309 [details] [diff] [review]
change the test to not run on 10.4

Maybe turn your comment into a warning dump().

Comment 16

[Robert Kaiser]

Attachment: hacky disabling of the test on Tiger (Darwin 8)

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.

Comment 17

[Boris Zbarsky [:bzbarsky]]

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

?

Comment 18

[Serge Gautherie (:sgautherie)]

(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.)

Comment 19

[Serge Gautherie (:sgautherie)]

(In reply to comment #18)
> ... but I could not find the bug/code where it happened.

Ah, got it: see patch in bug 448121 ! :-)

Comment 20

[Markus Stange [:mstange]]

Attachment: bz's comment as a patch [Checkin: Comment 31]

Thanks Boris, that works!

Comment 21

[(not currently active) Ted Mielczarek]

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.

Comment 22

[Mark Banner (:standard8)]

(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.

Comment 23

[Robert Kaiser]

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.

Comment 24

[Karsten Düsterloh]

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?

Comment 25

[Mark Banner (:standard8)]

(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?

Comment 26

[Karsten Düsterloh]

(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 27

[(not currently active) Ted Mielczarek]

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 28

[Mark Banner (:standard8)]

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 29

[Robert Kaiser]

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 30

[(not currently active) Ted Mielczarek]

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.

Comment 31

[Robert Kaiser]

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.

Comment 32

[Serge Gautherie (:sgautherie)]

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 !