Closed Bug 838726 Opened 7 years ago Closed 3 years ago
Service .get "Cur Work D" not working for B2G mochitests
This is an example mochitest that is showing this failure: 3 ERROR TEST-UNEXPECTED-FAIL | /tests/content/media/test/test_directoryserviceprovider.html | undefined - got false, expected We expected 'tests/content/media/test/320x240.ogv' to exist, but it doesn't! I think what dougt was trying me to show that Cc["@mozilla.org/file/directory_service;1"].getService(Ci.nsIProperties).get("CurWorkD", Ci.nsILocalFile); isn't working currently for b2g. Anyway, he said to file a bug for this and he would come up with a patch that would fix this issue. This code is used something like 20 times in mochitest, so once this is fixed, those test files could be removed from the exclude list.
dhylands, does getcwd work from the child process? CurWorkD basically means getcwd.
Perhaps CurWorkD needs to be added here? http://mxr.mozilla.org/mozilla-central/source/b2g/components/DirectoryProvider.js#55
Curiously, test_directoryserviceprovider.html doesn't seem to exist anymore.
Ok, "CurWorkD" doesn't seem to be used in tests anymore, only in manifest.js, but there is already a workaround made for Android, there should also be one made for b2g. See bug 564720, comment 16 and further.
Just to update this, I see similar requests to obtain the profile directory "ProfD" failing as well.
CurWorkD is actually a lot more complex to fix, and in order to do so we need to fake out the concept of CurWorkD. Normally mochitests are run locally. And there is an underlying file system which houses the tests directory. When we run tests on the emulator, the http server is proxying this data... There is no CurWorkD that is valid. The best that can be done is copying over the test files and maintaining a fake pointer to the copy of tests, so for all intensive purposes of the test it should work. However this adds complexity. The ideal is that the http server needs to run on the b2g device, and pipe the results back. Then you could both write to the file system, and then load that content in the same test.
Ok, the workaround is checked in bug 896582, which is a similar workaround as was used for Android. See bug 564720 comment 16. Would downloading the relevant files from inside the test and then using it for the test work, perhaps?
Marking WONFTIX, sorry for the bug spam. If somebody still wants to work on this, please open a new bug.
Status: NEW → RESOLVED
Closed: 3 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.