563601 - xpcshell-tests / test_handlerService.js fails on new Linux 64 bit box

Status: RESOLVED FIXED

(Mozilla Messaging Graveyard :: Release Engineering, defect)

Description

[Mark Banner (:standard8)]

We're getting a consistent failure on the new Linux 64 bit box on staging:

NEXT ERROR TEST-UNEXPECTED-FAIL | /buildbot/linux64-comm-1.9.1-check/build/objdir/mozilla/_tests/xpcshell/test_uriloader_exthandler/unit/test_handlerService.js | true == false - See following stack:
JS frame :: /buildbot/linux64-comm-1.9.1-check/build/mozilla/testing/xpcshell/head.js :: do_throw :: line 164
JS frame :: /buildbot/linux64-comm-1.9.1-check/build/mozilla/testing/xpcshell/head.js :: do_check_eq :: line 194
JS frame :: /buildbot/linux64-comm-1.9.1-check/build/mozilla/testing/xpcshell/head.js :: do_check_false :: line 213
JS frame :: /buildbot/linux64-comm-1.9.1-check/build/objdir/mozilla/_tests/xpcshell/test_uriloader_exthandler/unit/test_handlerService.js :: run_test :: line 155
JS frame :: /buildbot/linux64-comm-1.9.1-check/build/mozilla/testing/xpcshell/head.js :: _execute_test :: line 103

Analysis points to this section:

http://hg.mozilla.org/mozilla-central/annotate/fe433627820d/uriloader/exthandler/tests/unit/test_handlerService.js#l149

The actual failure being at line 155.

It implies to me that there isn't a default browser installed on that box. I'm not 100% sure if that is the case or not, but the way I read that test implies it is.

Comment 1

[Philippe M. Chiasson (:gozer)]

(In reply to comment #0)
> We're getting a consistent failure on the new Linux 64 bit box on staging:
> [...]
> 
> The actual failure being at line 155.
> 
> It implies to me that there isn't a default browser installed on that box. 

That's possible, the box is a really, really fresh automated install. Nobody ever ran a browser on it, for instance.

> I'm not 100% sure if that is the case or not, but the way I read that test implies it is.

What's the right fix for this? I can try and just install firefox, but I _really_ suspect this is the kind of registration that happens after first startup.

I'd rather find the correct gconf entry (or whatever) and stick something in there. Feels like a broken test assumption to me.

Comment 2

[Mark Banner (:standard8)]

I'm actually thinking that this is a broken set-up procedure for the Linux boxes. 

My assumption here is that someone has run something on the FF Linux 64 bit boxes (and 32 bit) ones that then sets it up right for running the test. The test has then been created and it runs fine and never knew about the broken set-up.

Maybe we can get one of the MoCo guys to have a poke around at gconf on these boxes?

Note that, in theory, our 32 bit Linux boxes should also be broken from what I can work out.

Comment 3

[Philippe M. Chiasson (:gozer)]

Looks like we need to make sure to have the gconf key : '/desktop/gnome/url-handlers/http/command' set to something, i.e.

'firefox %s'

Comment 4

[Philippe M. Chiasson (:gozer)]

Unfortunately, this doesn't seem to be enough:

var mybool = {}; Components.classes["@mozilla.org/uriloader/external-protocol-service;1"].getService(Components.interfaces.nsIExternalProtocolService).getProtocolHandlerInfoFromOS("http", mybool); mybool.value

gives 'false' and so does

Components.classes["@mozilla.org/uriloader/external-protocol-service;1"].getService(Components.interfaces.nsIExternalProtocolService).externalProtocolHandlerExists("http")

even though invoking gconf from the commandline gives:
 $> gconftool-2 -g /desktop/gnome/url-handlers/http/commandfirefox %s
 firefox %s

Comment 5

[Philippe M. Chiasson (:gozer)]

GConf2-devel didn't get installed on the linux64 refplatform builders for some reason, so gconf support was just silently dropped from these builds.

Comment 6

[Mark Banner (:standard8)]

The gconf change has definitely fixed the trunk builders.

1.9.2 are busted with an error I'm not sure about why we're getting it. Could we try clobber on those again?

The 1.9.1 builders are still broken wrt default browser. Did we clobber those, if not, can we try again?

Comment 7

[Mark Banner (:standard8)]

(In reply to comment #6)
> 1.9.2 are busted with an error I'm not sure about why we're getting it. Could
> we try clobber on those again?

Actually, this is probably to do with bug 572113.

Comment 8

[Philippe M. Chiasson (:gozer)]

This was indeed caused by missing GConf2-devel package, all is good now.