477594 - updater.ini needed for updater binary and xpcshell unittest: test_update/unit/test_0040_general.js fails to get update for %LOCALE%

Status: RESOLVED FIXED

(Firefox for Android Graveyard :: General, defect)

Description

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 1

[Joel Maher ( :jmaher ) (UTC -8)]

moving to toolkit:application update as this is specific to a test, not fennec.

Comment 2

[Robert Strong (they/them - no direct email)]

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

Comment 3

[Mark Finkle (:mfinkle) (use needinfo?)]

Adding Axel for direction on the INI, since it appears to be part of a locale

Comment 4

[Axel Hecht [:Pike]]

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.

Comment 5

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 6

[Joel Maher ( :jmaher ) (UTC -8)]

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

Comment 7

[Mark Finkle (:mfinkle) (use needinfo?)]

Attachment: patch

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.

Comment 8

[Mark Finkle (:mfinkle) (use needinfo?)]

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.

Comment 9

[(not currently active) Ted Mielczarek]

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.

Comment 10

[Axel Hecht [:Pike]]

On a related note, what does software update do in the case for a xulrunner application in the first place?

Comment 11

[(not currently active) Ted Mielczarek]

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.

Comment 12

[Robert Strong (they/them - no direct email)]

(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 13

[Robert Strong (they/them - no direct email)]

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

Comment 14

[Mark Finkle (:mfinkle) (use needinfo?)]

http://hg.mozilla.org/mobile-browser/rev/4ef27530dc88

not marking FIXED yet, until we determine if the xpcshell testcase is fixable.

Comment 15

[Brad Lassey [:blassey] (use needinfo?)]

any update on the xpcshell testcase?

Comment 16

[Robert Strong (they/them - no direct email)]

Bug 488936 will make it so XULRunner standalone passes this test which should also make it so the test passes on fennec.

Comment 17

[Robert Strong (they/them - no direct email)]

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?

Comment 18

[Robert Strong (they/them - no direct email)]

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

Comment 19

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 20

[Robert Strong (they/them - no direct email)]

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

Comment 21

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 22

[Robert Strong (they/them - no direct email)]

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.

Comment 23

[Joel Maher ( :jmaher ) (UTC -8)]

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.

Comment 24

[Robert Strong (they/them - no direct email)]

(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.

Comment 25

[Robert Strong (they/them - no direct email)]

Joel, thanks a lot for providing these details... I suspect I'll be able to come up with a fix next week.

Comment 26

[Robert Strong (they/them - no direct email)]

Filed Bug 495301 for the test_0050_general.js failure on Fennec

Comment 27

[Axel Hecht [:Pike]]

Filed bug 495467 to make updater.ini optional for l10n-merged builds.