l10n partial updates fail over to full update if Talkback is installed

RESOLVED FIXED

Status

()

Toolkit
Application Update
--
major
RESOLVED FIXED
12 years ago
9 years ago

People

(Reporter: tracy, Assigned: preed)

Tracking

({fixed1.8.0.1, fixed1.8.0.2})

1.8.0 Branch
x86
Windows XP
fixed1.8.0.1, fixed1.8.0.2
Points:
---
Bug Flags:
blocking1.8.0.2 +

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: [rft-dl])

Attachments

(2 attachments, 1 obsolete attachment)

(Reporter)

Description

12 years ago
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 1.5.0.1.

expected result:
The partial update is applied and the app restarts as 1.5.0.1

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

Comment 2

12 years ago
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.
(Reporter)

Comment 4

12 years ago
I forgot to mention that this bug is not affecting en-US.  so there may be clues there as well.

Comment 5

12 years ago
Likely related to bug 258625.

Axel, do we ask localizers to update readme.txt in the base of the installation?
(Reporter)

Comment 6

12 years ago
Interesting, zh-TW is also not affected.  

Comment 7

12 years ago
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.
(Assignee)

Comment 8

12 years ago
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
(Assignee)

Comment 9

12 years ago
Created attachment 210288 [details] [diff] [review]
Patch to make_incremental_update.sh to implement the above hack
Attachment #210288 - Flags: review?(darin)

Comment 10

12 years ago
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.

Comment 11

12 years ago
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.

Comment 12

12 years ago
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".)
(Reporter)

Comment 13

12 years ago
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.

(Reporter)

Comment 14

12 years ago
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.
(Assignee)

Comment 16

12 years ago
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.
Attachment #210288 - Attachment is obsolete: true
Attachment #210288 - Flags: review?(darin)

Comment 17

12 years ago
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?
(Assignee)

Comment 18

12 years ago
(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
Flags: blocking1.8.0.2?
Flags: blocking1.8.0.2? → blocking1.8.0.2+

Comment 19

12 years ago
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.
(Assignee)

Comment 20

12 years ago
This should not affect 1.5.0.2 users; the file was updated in 1.5.0.1, 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 1.5.0.2.
Keywords: fixed1.8.0.1, fixed1.8.0.2

Updated

12 years ago
Whiteboard: [rft-dl]
Has this been fixed on the 1.8 branch, or was it always specific to 1.8.0?
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.