328886 - Talkback Not Being Updated Properly

Status: RESOLVED FIXED

(Core Graveyard :: Installer: XPInstall Engine, defect)

Description

[Scott MacGregor]

I had a 1.8 build from 02/14/2006.

I just downloaded the 02/27 windows installer for 1.8 and ran it.

When I was done I ended up with the following:

1) A Firefox Build whose Help / About window said it was from 20060228. 
2) But the master.ini file said: BuildID = "2006021404"

Uhoh!

Note: I reached the 02/14 build using software update. Then the installer to jump ahead to 02/27.

Comment 1

[Scott MacGregor]

if this problem turns out to be wide spread and reproducible, it could become a 1.8.1 blocker.

Comment 2

[Jay Patel [:jay]]

Scott:  Did you do a custom install with the latest build and select Talkback?  Or did you do a standard install? (Talkback is only installed 20% of the time for standard installs on Windows)

I wonder if the installer isn't smart enough to delete the old Talkback files if Talkback is not selected during the most recent install.  I remember we had to make some changes to clean up old 1.0.x files when we made the changes to turn Talkback into an "extension".  Related?

If people can help verify this on other branches, that will be great.

Comment 3

[Scott MacGregor]

Jay, I only did a custom install.

But the installer should see that talkback is already there and is supposed to force inclusion of the extension.

This was on the 1.8 branch.

Comment 4

[Jay Patel [:jay]]

After talking with Scott, it looks like he did a Standard install with the 2/27 build and the installer (most likely) did not install Talkback (only 20% of Windows Standard installs enable Talkback by default).  In which case, it would not install any new files or overwrite the existing Talkback files from his previous updated build from 2/14.  

The bug seems to be that the installer also did not remove the old Talkback files (since the installer chose not to include Talkback by default).

I believe that Software Update is smart enough to know what is and is not installed and only update the files that it needs to (and even remove any specified files), so this shouldn't be a problem for users that are updating.

I am not sure if the installer shares/uses any of the Software Update config files to decide what it needs to install.  If it did, it should have known that Scott had Talkback installed and that it was successfully updated to his latest 2/14 build (before he decided to do a paveover install)...and successfully overwritten the Talkback files.  But it seems as if the installer simply goes by what the comonents selected through the installer (not by what files exist or what the update config/log file say).

So, I'm guessing the only case I see this problem happeing with is:

1. Run the installer and either
   a. choose Custom install, select the Mozilla Quality Feedback component (Talkback) to be installed.
   b. choose Standard install, be one of the lucky 20% to have Talkback installed by default.

2. Do as many updates as you want (or not), crash, submit Talkback incidents.

3. Decide to install a newer build in the same location with the installer and either:
   a. choose Custom install, make sure Talkback is unchecked (if that's even possible, since I was under the assumption that if you had a component already installed, the box would be checked by default and grayed out).
   b. choose Standard install, be one of the 80% that will not have Talkback enabled by default.

We'll have to do some testing to see exactly what is happening, but those steps should give users something to go on.

This is most likely an installer bug, so who should this be assigned to?

Comment 5

[Jay Patel [:jay]]

I posted to the QA blog: http://weblogs.mozillazine.org/qa/archives/2006/03/help_wanted_talkback_not_being.html, so hopefully we get some good testing from the community.  I will spend some time tomorrow testing this myself.

Comment 6

[Benjamin Smedberg]

I'm not sure this is a big deal: if we don't install the new talkback files the maxVersion for the talkback extension won't be revised, and the extension won't be enabled. So even in master.ini is incorrect it shouldn't matter.

Comment 7

[Jay Patel [:jay]]

bsmedberg:  The maxVersion doesn't change for the same branch/version of app builds, so I think Talkback would still be "enabled" in this case.  We'll see once some of the testers give some feedback... and I'll be sure to test submitting crashes as well.

Comment 8

[timeless]

i thought the old installer *forced* you to update all available installed components (in part to avoid this problem).

Comment 9

[Jenn Scott]

(In reply to comment #4)

> The bug seems to be that the installer also did not remove the old Talkback
> files (since the installer chose not to include Talkback by default).

That's what it seems to me - see my test below.

<snip>
> So, I'm guessing the only case I see this problem happeing with is:
> 
> 1. Run the installer and either
>    a. choose Custom install, select the Mozilla Quality Feedback component
> (Talkback) to be installed.
>    b. choose Standard install, be one of the lucky 20% to have Talkback
> installed by default.

I usually follow case 1a when I have to do a full install of a branch nightly, as has been the case lately.
 
> 2. Do as many updates as you want (or not), crash, submit Talkback incidents.

I haven't had any crashes since yesterday, so I didn't have any Talkback incidents, sorry.
 
> 3. Decide to install a newer build in the same location with the installer and
> either:
>    a. choose Custom install, make sure Talkback is unchecked (if that's even
> possible, since I was under the assumption that if you had a component already
> installed, the box would be checked by default and grayed out).
>    b. choose Standard install, be one of the 80% that will not have Talkback
> enabled by default.

When I went to install the 3/2 Win32 1.8 branch nightly to upgrade my 3/1 version of the same, I did 3a.  This is possible - I usually install both the Developer Tools and Quality Feedback, and always have to select both, as was the case this time.  So, this time I left Quality Feedback unchecked.  If I had been smarter and less tired, I would have seen if this affected DOM Inspector as well, as that's also considered an extension.
  
My initial build ID, from the 3/1 nightly (yes, I have Firesomething installed):
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060301 PowerPanther (All your null/null are belong to Firesomething) Firefox/1.5 - Build ID: 2006030105
The Talkback master.ini BuildID: 2006030105
Talkback status: enabled in Extensions Manager

After the custom install without selecting Talkback:
Build ID: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060302 Blue Eyes White Tuna (All your null/null are belong to Firesomething) Firefox/1.5 - Build ID: 2006030205
The Talkback master.ini BuildID: 2006030105
Talkback status: enabled in Extensions Manager

I then reran the 3/2 nightly installer, this time checking both DOM Inspector and Talkback:
BuildID: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060302 Black Dragon Reindeer (All your null/null are belong to Firesomething) Firefox/1.5 - Build ID: 2006030205
The Talkback master.ini BuildID: 2006030205
Talkback status: enabled in Extensions Manager

Hope this helps, as I head off to bed!

Comment 10

[Benjamin Smedberg]

Attachment: Fix force-upgrade path, rev. 1

Comment 11

[Jay Patel [:jay]]

Comment on attachment 213896 [details] [diff] [review]
Fix force-upgrade path, rev. 1

I had a feeling this bug might have something to do with the change to make Talkback an "extension".  It seems as if this will solve the remove/update old Talkback files problem, but what about making sure that all current Talkback users get to keep it when doing a Standard install?  Will this somehow magically fix that problem?

Comment 12

[Benjamin Smedberg]

Comment on attachment 213896 [details] [diff] [review]
Fix force-upgrade path, rev. 1

I'm not sure I understand the question. The force-upgrade code does the same thing in standard and custom install paths.

Comment 13

[Benjamin Smedberg]

fixed on trunk.

Comment 14

[Daniel Veditz [:dveditz]]

Comment on attachment 213896 [details] [diff] [review]
Fix force-upgrade path, rev. 1

approved for 1.8.0 branch, a=dveditz for drivers

Comment 15

[Benjamin Smedberg]

Fixed on the branches.

Comment 16

[Jay Patel [:jay]]

bsmedberg:  I was trying to ask whether or not the 20% Talkback install rate built into the Windows installer could be bypassed during a new Standard install if the user already has Talkback installed/enabled.  Does a Standard install know what to do the 80% of the time it DOESN'T decide to install Talkback if the user already has Talkback enabled?  Does it keep it enabled 100% of the time or only 20%?

Comment 17

[Benjamin Smedberg]

That's what the forceupgrade code is for: if the user has talkback installed, it forces talkback to be installed (standard or custom path are the same).

Comment 18

[Jay Patel [:jay]]

Ahh... ok, thanks for clearing that up.  I was under the impression that the forceupgrade code simply updated the Talkback files. I don't know how the code "enables" Talkback, so he assumed that happened somewhere else. Cool.  Thanks for the quick find and patch!

I'll verify this on Monday on the Trunk and both branches.

Comment 19

[Jay Patel [:jay]]

Reopening and removing the fixed1.8.0.2 keyword... something is still not right.

I only got around to testing the 1.8.0 branch today, but it looks like things work ok if you install over an existing install (the directory where you properly installed Firefox before, and a location that is still in the registry somewhere for that last version/build installed).  

I did the following to verify the case above:
1. Installed a 2/24 build twice. Once with Standard (after a few attempts to make sure Talkback was enabled by default), and then with Custom by manually selecting the Talkback component.  
2. Verified that Talkback was installed and the master.ini showed the correct 2/24 Build ID.
3. Installed today's 3/7 build twice.  Once with Standard (making sure the installer was going to install Talkback), and then again with Custom (making sure the Talkback component was properly selected automatically and grayed out so that I could not unselect it).
4. Each install successfully updated Talkback to use today's Build ID.

HOWEVER, there is still a problem with removing the Talkback files if I somehow DO get a chance to uncheck the Talkback component during a Custom install.  This only happens if you have multiple instances of Firefox installed in different directories... but it does expose the bug:

1. Uninstall the most recent older build of "Mozilla Firefox 1.5 " through Add/Remove Programs from location A, and remove that directory.  Confirm that there is no entry for Firefox in Add/Remove Programs.
2. Make sure you have another older build installed somewhere in location B (in my case it was the 2/24 build).
3. Install a new build over location B (i installed today's 3/7 build).
4. Depending on which type of install you do:
   a. For Standard install, I'm assuming Talkback is going to be installed because it should find the old Talkback files in that location, but there is no way to know...although during my first pave over install, Standard did update Talkback as expected (although there is still a possibility that if I tried enough times, that 80% would kick in and Talkback would not be installed, leading to same problem I will talk about next.
   b. For Custom install, Talkback is checked by default, but it is not grayed out. I am able to uncheck it (as Jenn was able to do in comment #9).  By doing that I am expecting Talkback to be removed with the new build and the old files deleted, but that isn't happening.  I end up with a 3/7 build with Talkback files for 2/24.

I understand that by creating such a state (uninstalling through Windows and then installing in a location that the system doesn't know about) I am asking for trouble, but I'm sure a lot of people do it.  I was unable to find a reproducible crash to see if I get "bad" Talkback data, but I'm assuming I would since the master.ini is there along with the other necessary Talkback files.  Unless I'm missing something and there is a way to "disable" Talkback even with those files there.

bsmedberg:  Any more info and explaination of what might be broken is appreciated.

Jenn:  Can you try installing over an old build with the latest nightly and see if you can reproduce the same problem you saw before?  Just do what you normally do and let us know if it's anything like what I described above.  Thanks!

Comment 20

[Benjamin Smedberg]

Jay, that's a different bug and has been present for ever. The installer checks the "current" installation for upgrade-forcing, not whichever one you choose for a custom install path. I don't feel it's serious enough to fix or even worry about, but if you do please find or file another bug.

Comment 21

[Jenn Scott]

Jay, I did my usual Custom install of the latest (3/7) Win32 nightly on top of of 3/6 1.8 Win32 nightly.  Quality Feedback has been grayed out and unselectable for me since the patch was checked in, and is checked.  I double checked, and I definitely can't uncheck it (although, in a similar vein, DOM Inspector can still be deselected, and in fact has been by default for me, even though I do have that installed - I recheck that every time.  I'm don't know if that needs to be updated every time, though).  The master.ini is correctly updated to BuildID = "2006030703", matching my Firefox ID (Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8) Gecko/20060307 Blue Eyes White Bat (All your null/null are belong to Firesomething) Firefox/1.5 - Build ID: 2006030703).  So, in short, WFM.

Comment 22

[Scott MacGregor]

putting back the fixed1.8.0.2 keyword since this bug got re-closed.