Closed Bug 477594 Opened 12 years ago Closed 12 years ago
.ini needed for updater binary and xpcshell unittest: test _update/unit/test _0040 _general .js fails to get update for %LOCALE%
this unit test passes 9 other tests, but fails to pass the test that references http//localhost:4444/data/%LOCALE%/. When it runs, it just hangs on this test. If I remove this specific test from the .js file, it passes everything else.
moving to toolkit:application update as this is specific to a test, not fennec.
Component: General → Application Update
Product: Fennec → Toolkit
QA Contact: general → application.update
Summary: xpcshell unittest: test_update/unit/test_0040_general.js fails to get update for %LOCALE% → [Fennec] xpcshell unittest: test_update/unit/test_0040_general.js fails to get update for %LOCALE%
fennec needs to provide an updater.ini just as other apps do and in this file the installation locale is provided which is why this test fails. http://mxr.mozilla.org/mozilla-central/source/browser/locales/en-US/updater/updater.ini and http://mxr.mozilla.org/mozilla-central/source/browser/locales/updater_append.ini along with the appropriate Makefile.in magic
Component: Application Update → General
Product: Toolkit → Fennec
QA Contact: application.update → general
Summary: [Fennec] xpcshell unittest: test_update/unit/test_0040_general.js fails to get update for %LOCALE% → updater.ini needed for updater binary and xpcshell unittest: test_update/unit/test_0040_general.js fails to get update for %LOCALE%
Adding Axel for direction on the INI, since it appears to be part of a locale
Robert, do you know of a reason why we didn't put updater.ini into toolkit? The three files in comm-central have the same content as the one in browser. Given string freeze on 1.9.1 and fennec's desire to move to that tree, we might just have to go for the forth clone of it, though.
this specific test is timing out for me. In the new rewrite of runxpcshelltest.py by ted, this test causes the harness to hang when run for Fennec.
So I tried this out and found that copying a updater.ini from a firefox build to the fennec/xulrunner/ directory resolved my problem. Here is what my updater.ini looks like: ; This file is in the UTF-8 encoding [Strings] Title=Minefield Update Info=Minefield is installing your updates and will start in a few moments… ; IMPORTANT: This file should always start with a newline in case a locale ; provided updater.ini does not end with a newline. [Installation] Locale=en-US
This patch adds the locales/en-US/updater/updater.ini, locales/updater_append.ini files. It also adds some code to the locales/Makefile.in to create the final updater.ini file. Basically a copy of the Firefox process except we don't do any special installer for Windows.
Assignee: nobody → mark.finkle
Just a note: This will not fix the xpcshell test failure. xpcshell is being run from the fennec/xulrunner folder and so the test expects the updater.ini to live there too.
Yeah, I'm not really sure how to fix this test for the Fennec case, running from a packaged build. Ideally, with a fix for bug 483202, we'd just be running xpcshell from a completely separate directory, with -g path/to/xulrunner. In that case, this code would look for updater.ini wherever the xpcshell binary lives, which isn't going to work.
On a related note, what does software update do in the case for a xulrunner application in the first place?
The code that looks for updater.ini in this case would do the right thing if run from a stub executable in the appdir, since it uses XCurProcD: http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/src/nsUpdateService.js.in#80 http://mxr.mozilla.org/mozilla-central/source/toolkit/mozapps/update/src/nsUpdateService.js.in#521 If you ran /path/to/xulrunner /path/to/application.ini, then I think it would not work properly.
(In reply to comment #4) > Robert, do you know of a reason why we didn't put updater.ini into toolkit? The > three files in comm-central have the same content as the one in browser. I wasn't around for this but I suspect that it has to do with that it had the app name hardcoded originally which I recently fixed... or it could be for the same reason I was asked to make all of the installer l10n strings part of the app.
Comment on attachment 368914 [details] [diff] [review] patch Though I am not a fennec reviewer I added the current implementation for what it is worth so adding r+ for what it is worth
Attachment #368914 - Flags: review+
http://hg.mozilla.org/mobile-browser/rev/4ef27530dc88 not marking FIXED yet, until we determine if the xpcshell testcase is fixable.
any update on the xpcshell testcase?
Bug 488936 will make it so XULRunner standalone passes this test which should also make it so the test passes on fennec.
I found an issue with the way xpcshell runs interactive tests that rather surprised me. Turns out that the tail file is loaded prior to _execute_test which breaks the app update tests whereas if the test is run normally it loads it after the test runs. I modified the app update tests in Bug 493805 to fix this. Could you run the test again to see if it still fails and if it does could you run it again with the patch from bug 488936 to see if it fixes it?
Bug 493805 and Bug 488936 have landed on both trunk and 1.9.1. At this point even standalon xulrunner passes all tests. Can you please test again and provide any errors returned? Thanks
I have verified this test passed on the latest bits (did a hg pull/update from m-c this morning). Although a new test fails 0050, it appears to be a different beast. Thanks for following up on this bug. I am marking as resolved/fixed as it works on the device.
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Joel, can I get an update of all the tests that are failing? Such as bug 477596, bug 477597, and any ones that haven't been filed? Thanks
I will double check the results tonight/this weekend. rs, I know you are out of town for most of next week. Look for a list of bugs, and I will reference that in this bug for all to see.
Thanks Joel. In case you don't know both test_0110_general.js and test_0111_general.js won't pass until after bug 458950 is fixed and since these two tests only test the updater binary now they should just work after bug 458950 is fixed.
oddly enough both test_0110_general.js and test_0111_general.js are working (verified it with two separate runs) on the latest builds (running directly on my nokia maemo device). The only test_updates case that fails is test_0050*. Here is the output from that test: Nokia-N810-36-5:/media/mmc1/release/xpcshell/tests/test_update/unit# cat test_0050_general.js.log *** test pending *** test pending *** AUS:SVC UpdateService:canUpdate - testing /media/mmc1/release/fennec/xulrunner/update.test *** AUS:SVC General:getUpdatesDir - update directory /media/mmc1/release/fennec/xulrunner/updates/0 doesn't exist, creating... *** AUS:SVC UpdateService:canUpdate - testing /media/mmc1/release/fennec/xulrunner/updates/0/update.test *** AUS:SVC UpdateService:canUpdate - able to update *** AUS:SVC General:readStringFromFile - file doesn't exist: /media/mmc1/release/fennec/xulrunner/updates/0/update.status *** AUS:SVC General:readStatusFile - status: null, path: /media/mmc1/release/fennec/xulrunner/updates/0/update.status *** AUS:SVC UpdateService:_postUpdateProcessing - no status, no update *** AUS:SVC UpdateManager:_loadXMLFileIntoArray: XML file does not exist *** test finished *** running event loop Testing: run_test_pt1 - network is offline *** AUS:SVC Checker:getUpdateURL - update URL: http://localhost:4444/update.xml?force=1 *** AUS:SVC Checker:checkForUpdates - sending request to: http://localhost:4444/update.xml?force=1 Nokia-N810-36-5:/media/mmc1/release/xpcshell/tests/test_update/unit# In general on other tests, there are more tests from the beginning of the year when I initially got these running and investigated. jan 2009: tests passed: 499 tests failed: 25 total tests: 524 May 2009: tests passed: 516 tests failed: 67 total tests: 583 As you can see, we have 59 more tests that are run in May and a lot of additional failures. got my work cut out for me tracking these all down.
(In reply to comment #23) > oddly enough both test_0110_general.js and test_0111_general.js are working > (verified it with two separate runs) on the latest builds (running directly on > my nokia maemo device). Those tests fail on WinCE / WinMobile (I have to use an emulator myself since I don't have a maemo device) and not on maemo which does build the updater binary.
Joel, thanks a lot for providing these details... I suspect I'll be able to come up with a fix next week.
Filed Bug 495301 for the test_0050_general.js failure on Fennec
You need to log in before you can comment on or make changes to this bug.