I've tested de, es-ES, fi, mk, and pl on releasetest and betatest channels. This failure hapens on all on Windows. I haven't checked on Mac or Linux yet. steps to repro: -install a 1.5 l10n release build. -launch, then shut down. -edit C:\Program Files\Mozilla Firefox\defaults\pref\channel-prefs to read: pref("app.update.channel", "releasetest"); save changes -launch Firefox -go to Help | Check for Updates... -Dowload the update notice a partial update is downloaded -Click restart tested results: on restart the partial update is not applied. Instead the backgrounded window for a full update is present. Proceeding with that downloads a full update, asks for a restart then applies the full update to 22.214.171.124. expected result: The partial update is applied and the app restarts as 126.96.36.199 jay filed bug 316630. But I'm not sure that this is what he was seeing.
This is the last-update.log after trying to update win32 1.5 de on releasetest: PREPARE PATCH browserconfig.properties PREPARE PATCH xpicleanup.exe PREPARE ADD softokn3.chk PREPARE PATCH README.txt LoadSourceFile failed failed: 8 calling QuitProgressUI Seems to be the same error as bug 316630. I saw the same partial update failure and failover to full update (didn't wait for that to finish).
I see the same failure with sv-SE. But when I replace the <program dir>/readme.txt file with the localized readme.txt from the 1.5 installer, the partial update is successful. Could it be that the update need to see the localized readme.txt from the 1.5 installer sv-SE.xpi? That file is overwritten if Talkback is installed. See bug 317139.
Created attachment 210253 [details] Last update log when peforming update I am attaching my log - I saw the same failure that Tracy did when running the ar build.
I forgot to mention that this bug is not affecting en-US. so there may be clues there as well.
Likely related to bug 258625. Axel, do we ask localizers to update readme.txt in the base of the installation?
Interesting, zh-TW is also not affected.
el, en-GB, es-AR, ga-IE, gu-IN, he, hy-AM, ko, mn, zh-CN, and zh-TW have not localized the readme.txt file.
It looks like the problem is that the talkback.xpi file pulls its README during the build process from en_US; when (some) localizers localize this file, that locale package will clobber the talkback.xpi's README. This turns out to only be a problem on Win32, because other OSes respect the case differences between talkback's version ("README.txt") and the included version ("ReadMe.txt"). When a patch is created, it will find the localized readme.txt on Win32, and since the CRC won't match, it will fail, and pull the complete update. The patch I'm about to attach solves this problem by patching the update manifest generation script to ignore README.txt files (under the assumption that it's part of talkback.xpi), and forcefully update via an "add" command ReadMe.txt. This will cause everyone who receives this update to be forcefully updated to the localized ReadMe.txt, basically ignoring the README.txt It's unclear whether this is a longterm solution to the problem; it likely isn't. Taking, since I'm working on it.
Assignee: nobody → preed
Created attachment 210288 [details] [diff] [review] Patch to make_incremental_update.sh to implement the above hack
The path looks like a good starter (can we rename the talkback readme to README-talkback.txt in the future to resolve that conflict for all OS?), but looking at the patch, there is a "readme.txt" and a "README.txt", but no "ReadMe.txt", which confuses me. Without looking any closer, though.
PS: another reason this problem is windows only is that we only have optional components in the installer on windows, all other platforms just plain install everything, so the patch maker finds the same version of the installed files.
Just to sanity check the new update patch files, I tested de and enUS on Linux and things worked as expected: betatest/partial - PASS releasetest/partial - PASS releatstest/full - PASS (forced full update by hacking the update.status file to say "failed" instead of "pending" after downloading the partial patch and clicking "Later".)
With talk back installed I tested de and en-US on releasetest and betatest channels. partial update applied correctly on restart as expected. forced full updates applied correctly and just to be safe, checked partial update on betatest channel for de with talkback not installed. the partial update applied correctly.
above comments were regarding windows builds
Sanity check on Mac passes for en-US and de - ran both a partial update on releasetest channel, and forced a failure of partial/fallover to full and everything passed.
Created attachment 210309 [details] [diff] [review] Updated patch Previous patch worked, but updated everyone to the talkback version of the readme, not the localized version. This reverses the cases of the readme strings, and should update everyone to the exepcted localized version.
Can you please post a comment somewhere how to handle this situation as a user when she tries to update? Can I force FF to install the update or do I have to use the full download?
(In reply to comment #17) > Can you please post a comment somewhere how to handle this situation as a user > when she tries to update? > > Can I force FF to install the update or do I have to use the full download? No users should've encountered this problem. Even if they did, it would still be mostly transparent: the partial (smaller) update would fail, and the complete update would be downloaded. It would take longer to update, but other than that, they wouldn't notice a difference.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
We should follow the instructions in https://bugzilla.mozilla.org/show_bug.cgi?id=258625#c42 and remove README.txt from the talkback XPI - it just makes things confusing.
This should not affect 188.8.131.52 users; the file was updated in 184.108.40.206, so it shouldn't be a problem. But even if it is a problem, the patch still exists in the update system to ignore the README. Maybe we should remove the readme from talkback, but I'll let Jay/etc. comment on that. As for this bug, we should be fine for 220.127.116.11.
Keywords: fixed18.104.22.168, fixed22.214.171.124
Has this been fixed on the 1.8 branch, or was it always specific to 1.8.0?
9 years ago
Duplicate of this bug: 316630
You need to log in before you can comment on or make changes to this bug.