Closed Bug 562967 Opened 14 years ago Closed 14 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
normal

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

Attachment

General

Created:
Updated:
Size: