307566 - Talkback is being disabled with FF15b1 builds (when using an old profile)

Status: VERIFIED FIXED

(Toolkit :: Add-ons Manager, defect)

Description

[Jay Patel [:jay]]

With a profile I created a while back with a Deer Park trunk build from July, I
am seeing some weird behavior during the extensions compatibility check with the
Beta 1 candidate from today 20050908.  The Talkback extension is being reported
to not be compatible and since there is no way to get an update for that (it's
part of the install and only available as an extension as part of the app)...it
is disabled with Beta 1.

Not sure why umo/amo is detecting it as a regular extension and disabling it,
but that is not a good thing.

Comment 1

[Jay Patel [:jay]]

Attachment: Compatibility dialog showing Talkback

Comment 2

[Jay Patel [:jay]]

Nominating as a blocker, since many Linux users will likely run into this
problem...due to the fact that we have not supported Software Update on that
platform until recently.

It also seems as if my profile was created around 7/7 using a Deer Park build
(which I believe was off the Trunk)

Comment 3

[Asa Dotzler [:asa]]

Do you run into this with an upgrade from 1.0.6 to 1.5b1's rc?

- A

Comment 4

[Jay Patel [:jay]]

I do not see this with a clean profile created with 1.0.5 or 1.0.6.  With those
profiles, FF15b1 starts normally (after working around a focus issue I just
logged in bug 307567)...and Talkback is left alone.

We need to figure out what in my profile is causing the update mechanism to
treat it the way it does... because although most of our users will have 1.0.5
or 1.0.6, I bet they created their profiles sometime before then or maybe even a
new one with a Trunk nightly after those releases.

If anyone needs to take a look at files on my computer or if you have any ideas
on places to look to see if Talkback is being written to files it shouldn't
be...let me know.

Comment 5

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

It sounds like you have an old version of talkback and software update didn't
update it... it wasn't disabled by AMO - it was disabled based on the old
compatibility data from the original install of talkback as an extension.

Comment 6

[Jay Patel [:jay]]

What I'm saying is that there should be no "old compatibility data"...because I
DID install the latest version of Talkback when I installed the FF15b1 build. 
Talkback is installed during the install as an "extension"...but I don't think
it's the same "type" of extension as others, and therefore don't expect any
Software Update functionality to mess with it.

Comment 7

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

There can be old compatibility info in the extensions datasource which is
located in the profile. App compatibility applies to app installed extensions
the same as it does for regular extensions but they of course should be updated
with the app. They are different in that extensions installed into the app
extensions dir with appManaged="true" in their install.rdf are not checked for
updates. This may be the same issue as bug 307559 or a variation of it.

Comment 8

[Jay Patel [:jay]]

Attachment: Terminal showing server checking for update

So according to the terminal messages, it looks like the server is checking for
updates to Talkback. I've tried digging in the extensions directory and the
extensions.* files, but have not been able to notice any differences between my
old profile and recent ones created with 1.0.6 and 1.5b1...if anyone can gather
more info from the attached screenshot about where to look, let me know and I
can investigate further.

Also, if it would help, I can just tar up my profile directories and attach
them here (or email them to you if you want to take a look yourself).

Comment 9

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

Jay - Darin initially prevented checking for updates to talkback when it was
first made into an extension by adding an updateURL of about:blank... updates
were checked against about:blank which returned nothing. Now it uses the
appManaged property to prevent updates.

Can you verify that you have talkback installed in the application's extensions
directory of the system that printed those console messages? If you do could you
attach the install.rdf for it to this bug?

Comment 10

[Jay Patel [:jay]]

Attachment: [e-mail] install.rdf file for 1.5b1 (2005090805)

The file looks fine to me...and seems to work using other profiles created with
1.0.5, 1.0.6 and 1.5b1.  Something is fishy with my profile...I don't think
anything in the 1.5b1 app directory is causing this problem.

Comment 11

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

Thanks, the file when compared to the console output provided much needed
info... the console output was not for that install.rdf so the update check is
happening since your profile's extensions.rdf which is where that data is read
from doesn't have the appManaged property. This is also happening before the
upgrade of talkback since it is using this old install.rdf info per the console
output which also shows it is looking at about:blank... talkback is then
disabled. After that it should have found the updated install.rdf in the app's
extensions/[e-mail] directory and re-enabled talkback. Now I have
something to go on.

Comment 12

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

I'll try to finish up a patch for this by this evening.

Comment 13

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

Jay - if you could send me the extensions.rdf, extensions.cache, and
extensions.ini from the profile that experiences this to my bugzilla email it
may help with my testing of the patch this evening. Thanks.

Comment 14

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

Attachment: patch in progress

Extracts the contents.rdf files for extensions during install so when they are
read to create the chrome.manifest they aren't in the jar file which prevents
the zip reader cache. This is needed since during an upgrade we may have
multiple installs for a single item (e.g. upgrade from 1.0.x to 1.5, extension
is installed but is not compatible, upgrade for an extension is then found, and
the item is then upgraded). I did this for themes already a while ago.

Comment 15

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

Attachment: patch

Since the zip reader cache keeps coming back to haunt me I went ahead and
extracted the contents.rdf files for creating the chrome.manifest files instead
of reading them from inside the jar files. I had already done this for themes
and Ben did this a while ago for the install.rdf files so this is the last of
them. This allows us to have more than one install during a single startup and
should also reduce startup time during an upgrade though that isn't all that
important since upgrades don't happen all that often.

This allowed me to finish the installs prior to getting to the compatibility
update so the metadata for updated extensions supplied by the app can be
updated beforehand.

I added a helper function for getting a zip reader... this way if it fails we
can be assured that it gets closed before returning which has caused problems
in the past.

I also added a check for whether the location can be written to in
getItemLocation which fixes bug 308501.

Comment 16

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

Comment on attachment 197014 [details] [diff] [review]
patch

holding off on review until I can test this more thoroughly... probably by this
evening.

Comment 17

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

Attachment: patch

Comment 18

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

Fixed on trunk

Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--
 nsExtensionManager.js.in
new revision: 1.157; previous revision: 1.156

Comment 19

[Mike Schroepfer]

Comment on attachment 197112 [details] [diff] [review]
patch

Approved per 9/26 bug triage meeting.

Comment 20

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

Checked in to MOZILLA_1_8_BRANCH

Checking in mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in;
/cvsroot/mozilla/toolkit/mozapps/extensions/src/nsExtensionManager.js.in,v  <--
 nsExtensionManager.js.in
new revision: 1.144.2.13; previous revision: 1.144.2.12