Closed Bug 562967 Opened 10 years ago Closed 9 years ago

unit test fail: xpcshell\tests\test_uriloader_exthandler\unit\test_handlerService.js

Categories

(Core Graveyard :: File Handling, defect)

x86
Windows 7
defect
Not set

Tracking

(Not tracked)

RESOLVED FIXED
mozilla2.0b3

People

(Reporter: anodelman, Assigned: Dolske)

References

Details

Attachments

(1 file)

WINNT 6.1 mozilla-central opt test xpcshell

TEST-UNEXPECTED-FAIL | c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\tests\test_uriloader_exthandler\unit\test_handlerService.js | test failed (with xpcshell return code: 0), see following log:
  >>>>>>>
  *** HandlerServiceTest: getFile: requesting UMimTyp
  TEST-INFO | (xpcshell/head.js) | test 1 pending
*** HandlerServiceTest: getFile: requesting TmpD
*** HandlerServiceTest: the following NS_ERROR_FAILURE exception in nsIDirectoryServiceProvider::getFile is expected, as we don't provide the 'TmpD' file
TEST-UNEXPECTED-FAIL | c:/talos-slave/mozilla-central-win7-opt-u-xpcshell/build/xpcshell/tests/test_uriloader_exthandler/unit/test_handlerService.js | true == false - See following stack:
JS frame :: c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\head.js :: do_throw :: line 257
JS frame :: c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\head.js :: do_check_eq :: line 287
JS frame :: c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\head.js :: do_check_false :: line 306
JS frame :: c:/talos-slave/mozilla-central-win7-opt-u-xpcshell/build/xpcshell/tests/test_uriloader_exthandler/unit/test_handlerService.js :: run_test :: line 174
JS frame :: c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\head.js :: _execute_test :: line 151
JS frame :: -e :: <TOP_LEVEL> :: line 1
Dolske: can you take a look at this and help diagnose the test failure. Seems unexpected, yet expected?
Is this one of the perma-oranges blocking deployment of new boxes?

Also, is there a link to a log with this failure?

(In reply to comment #0)

> *** HandlerServiceTest: getFile: requesting TmpD
> *** HandlerServiceTest: the following NS_ERROR_FAILURE exception in
> nsIDirectoryServiceProvider::getFile is expected, as we don't provide the
> 'TmpD' file

I think this is expected, but poor logging output. Tinderbox is down right now, but I think it'll show up in existing logs.

> TEST-UNEXPECTED-FAIL |
...
> c:/talos-slave/mozilla-central-win7-opt-u-xpcshell/build/xpcshell/tests/test_uriloader_exthandler/unit/test_handlerService.js
> :: run_test :: line 174

This is the real failure (long after TmpD is touched, and midway through the test).

167   // OS default exists, injected default exists, explicit warning pref: false
168   prefSvc.setBoolPref(kExternalWarningPrefPrefix + "mailto", false);
169   protoInfo = protoSvc.getProtocolHandlerInfo("mailto");
170   if (haveDefaultHandlersVersion)
171     do_check_eq(2, protoInfo.possibleApplicationHandlers.length);
172   else
173     do_check_eq(0, protoInfo.possibleApplicationHandlers.length);
174   do_check_false(protoInfo.alwaysAskBeforeHandling);

The test is expecting there to be an OS-provided default for mailto handlers, which (iirc) means that we default to not asking when handling the protocol (under the assumption that if there's an OS default for it, you don't want to be asked).

I suspect what's happening here is that this box doesn't have a default email client set. Which isn't surprising, since Windows 7 doesn't come with one, so this is the first time this test has been running on an OS that didn't supply one.

The fix here is probably to modify the test to treat Windows 7 as a special case. [Or, more generically, have the test check if the OS really has a default mailto handler, but I'm not sure if that's possible.]
Assignee: nobody → dolske
Hi dolske,
We are now running these on production but hidden.
This is one of the 4 test suites left to greenize on Windows 7 and we want to make this green as soon as it is possible to help us move load from the Win2k3 machines to the Win7 machines (it will really help us). Any help that you can give us will be really appreciate it.

You can find logs for it under:
http://tinderbox.mozilla.org/showbuilds.cgi?tree=Firefox&noignore=1
as:
* Rev3 WINNT 6.1 mozilla-central opt test xpcshell

Here is one of the logs:
http://tinderbox.mozilla.org/showlog.cgi?log=Firefox/1277826882.1277831427.19849.gz

The output as of now is:
TEST-UNEXPECTED-FAIL | c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\tests\test_uriloader_exthandler\unit\test_handlerService.js | test failed (with xpcshell return code: 0), see following log:
  >>>>>>>
  *** HandlerServiceTest: getFile: requesting UMimTyp
TEST-INFO | (xpcshell/head.js) | test 1 pending
*** HandlerServiceTest: getFile: requesting TmpD
*** HandlerServiceTest: the following NS_ERROR_FAILURE exception in nsIDirectoryServiceProvider::getFile is expected, as we don't provide the 'TmpD' file

...

TEST-UNEXPECTED-FAIL | c:/talos-slave/mozilla-central-win7-opt-u-xpcshell/build/xpcshell/tests/test_uriloader_exthandler/unit/test_handlerService.js | true == false - See following stack:
JS frame :: c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\head.js :: do_throw :: line 257
JS frame :: c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\head.js :: do_check_eq :: line 287
JS frame :: c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\head.js :: do_check_false :: line 306
JS frame :: c:/talos-slave/mozilla-central-win7-opt-u-xpcshell/build/xpcshell/tests/test_uriloader_exthandler/unit/test_handlerService.js :: run_test :: line 174
JS frame :: c:\talos-slave\mozilla-central-win7-opt-u-xpcshell\build\xpcshell\head.js :: _execute_test :: line 151
JS frame :: -e :: <TOP_LEVEL> :: line 1
TEST-INFO | (xpcshell/head.js) | exiting test

  <<<<<<<
Any updates?
You can also find the current logs by going to:
http://tests.themasta.com/tinderboxpushlog/?noignore=1
and looking for the "Xo" build on the Win7 line.
Armen - can you install a mailto handler on one of the win7 boxes and see if it confirms dolske's suspicions?

dolske - if you're right - do we gin up a way to check for an OS-supplied default, or just ifdef it out?
(In reply to comment #6)
> Armen - can you install a mailto handler on one of the win7 boxes and see if it
> confirms dolske's suspicions?
> 
> dolske - if you're right - do we gin up a way to check for an OS-supplied
> default, or just ifdef it out?

I can loan a Win7 machine for dolske to try his theory if he doesn't have a machine. I can then do changes on the pool if that is required.
Attached patch Patch v.1Splinter Review
This seems like the simplest way to get the test green.
Attachment #459163 - Flags: review?(robert.bugzilla)
Comment on attachment 459163 [details] [diff] [review]
Patch v.1

Wish there were a better way to do this... we can't use the mock registry since this is using the application association interface to get the mailto handler though the application association interface *might* return the mailto handler from classes if it is set under HKCU. :(

Might be a good thing to have the test add a mailto handler under HKCU if it doesn't exist and remove it after the test if it added it... followup bug to investigate if that would fix this as well?
Attachment #459163 - Flags: review?(robert.bugzilla) → review+
Pushed http://hg.mozilla.org/mozilla-central/rev/53255ac811ff

(In reply to comment #9)
> Might be a good thing to have the test add a mailto handler under HKCU if it
> doesn't exist and remove it after the test if it added it... followup bug to
> investigate if that would fix this as well?

Filed bug 580818.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla2.0b3
This test is now green, but looks like the Win7 box is being bitten by bug 562489 now, so the test run is not yet green.
Sigh, pastefail, I meant bug 561350.
Product: Core → Core Graveyard
You need to log in before you can comment on or make changes to this bug.