Closed
Bug 563601
Opened 15 years ago
Closed 15 years ago
xpcshell-tests / test_handlerService.js fails on new Linux 64 bit box
Categories
(Mozilla Messaging Graveyard :: Release Engineering, defect)
Tracking
(Not tracked)
RESOLVED
FIXED
People
(Reporter: standard8, Assigned: gozer)
References
Details
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.
Assignee | ||
Comment 1•15 years ago
|
||
(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.
Reporter | ||
Comment 2•15 years ago
|
||
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.
Assignee | ||
Comment 3•15 years ago
|
||
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'
Assignee | ||
Comment 4•15 years ago
|
||
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
Assignee | ||
Comment 5•15 years ago
|
||
GConf2-devel didn't get installed on the linux64 refplatform builders for some reason, so gconf support was just silently dropped from these builds.
Reporter | ||
Comment 6•15 years ago
|
||
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?
Reporter | ||
Comment 7•15 years ago
|
||
(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.
Assignee | ||
Comment 8•15 years ago
|
||
This was indeed caused by missing GConf2-devel package, all is good now.
Status: NEW → RESOLVED
Closed: 15 years ago
Resolution: --- → FIXED
You need to log in
before you can comment on or make changes to this bug.
Description
•