325633 - FF 1.5.0.1 does not consult my update.rdf file

Status: RESOLVED DUPLICATE of bug 318793

(Toolkit :: Add-ons Manager, defect)

Description

[Godmar Back]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

Firefox upgraded to 1.5.0.1 and disabled my extension.
The extension had a maxVersion of 1.5 (which I thought would include 1.5.0.*). This is not the bug, however.  I built a new version of my extension and updated my update.rdf file to point to that new version.

However, Firefox 1.5.0.1 will *NOT* contact my server for the update.rdf file. I verified this using the server logs, and using a packet sniffer on the client machine.  However, the JavaScript Console says this:

Datasource: Update Started
Datasource: Addon Update Started: {d75de36c-af0d-4dc2-b63a-0d482d4b9815}
RDFItemUpdater:checkForUpdates sending a request to server for: http://www.libx.org/editions/vt/update.rdf, item = ({id:"{d75de36c-af0d-4dc2-b63a-0d482d4b9815}", version:"1.0.1", installLocationKey:"app-profile", minAppVersion:"1.0", maxAppVersion:"1.5", name:"LibX Virginia Tech", xpiURL:"none", xpiHash:"", iconURL:"chrome://mozapps/skin/xpinstall/xpinstallItemGeneric.png", updateRDF:"http://www.libx.org/editions/vt/update.rdf", type:2})
Datasource: Addon Update Ended: {d75de36c-af0d-4dc2-b63a-0d482d4b9815}, status: 8
Datasource: Update Ended

This means my extension will break for everyone who has installed it.  Great.

(Uninstalling and reinstalling the extension works fine on FF 1.5.0.1)

 - Godmar


Reproducible: Always

Steps to Reproduce:
Upgrade to 1.5.0.1

Comment 1

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

I am quite sure you are seeing a cached version of the rdf data and I believe there is already a bug on that.

Comment 2

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

btw: I believe it will find the new data in the rdf (e.g. not read it from the cache) within 24 hours.

Comment 3

[Godmar Back]

Indeed, it appears to be due to a cached update.rdf.

Would it be unreasonable to flush the cache when upgrading to a new version?

Comment 4

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

I'm not sure how flushing the cache when upgrading to a new version would solve this but I may just be dense. Currently, the EM sets no-cache on the XMLHttpRequest for the rdf but it doesn't appear to have the desired affect. You should also be able to set the server to tell the client not to cache but I haven't checked if it is honored. Since extension developers are the only people that see this and it doesn't cause any significant harm (e.g. it corrects itself within 24 hours iirc) besides causing a scare this hasn't been a high priority.

Comment 5

[Godmar Back]

(In reply to comment #4)
> I'm not sure how flushing the cache when upgrading to a new version would solve
> this but I may just be dense. Currently, the EM sets no-cache on the
> XMLHttpRequest for the rdf but it doesn't appear to have the desired affect.
> You should also be able to set the server to tell the client not to cache but I
> haven't checked if it is honored. Since extension developers are the only
> people that see this and it doesn't cause any significant harm (e.g. it
> corrects itself within 24 hours iirc) besides causing a scare this hasn't been
> a high priority.
> 

If the user checks for an update, you must not look at cached data, it's as simple as that.

Comment 6

[Godmar Back]

(In reply to comment #4)
> Since extension developers are the only
> people that see this and it doesn't cause any significant harm (e.g. it
> corrects itself within 24 hours iirc) besides causing a scare this hasn't been
> a high priority.
> 

You may be misunderstanding the problem.

Extensions are the only reason to even touch Firefox, and if they constantly break - for users, not just "extension developers" - it's back to IE for most of them. Making sure that extensions do not break when you upgrade should be a high priority for you.

Comment 7

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

Yes, this bug needs to be fixed... there are several bugs that have a greater impact so bug 318793 hasn't been on my radar. Also, this doesn't break extensions for users except possibly in an edgecase for a small number of users and even in this case it will find the update within 24 hours from the occurrence.

Any help getting the call to XMLHttpRequest to not cache the data when the EM retrieves the data would be appreciated.

*** This bug has been marked as a duplicate of 318793 ***

Comment 8

[Godmar Back]

(In reply to comment #7)
> Yes, this bug needs to be fixed... there are several bugs that have a greater
> impact so bug 318793 hasn't been on my radar. Also, this doesn't break
> extensions for users except possibly in an edgecase for a small number of users
> and even in this case it will find the update within 24 hours from the
> occurrence.

This wasn't much solace for one of our team members who had Firefox upgrade on all the machines in a teaching lab right in the middle of a presentation and was unable to demo our extension because of this.

Also, it's not working on in all cases after 24 hours. In one profile on a version of FF running on Windows, "Find Update" still reports it can't find the update, well after 24 hours. Maybe the bug is more insidious than that.

 

Comment 9

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

(In reply to comment #8)
> Also, it's not working on in all cases after 24 hours. In one profile on a
> version of FF running on Windows, "Find Update" still reports it can't find the
> update, well after 24 hours. Maybe the bug is more insidious than that.
That would be a different bug and it would be a good thing if the uniqueness of that system were to be isolated so the cause could be found and then a bug filed for it.

Comment 10

[Godmar Back]

It's not a different bug. I loaded the URL of the update.rdf directly into the browser and clicked "View Page Info" to see what time Firefox thinks the file would expire at.  It was Feb 7, which is next week.  I then flushed the cache and was able to update.

Since my server does not send any cache control headers, it is up to the client to decide what a reasonable time to cache this file is.  I do not know how Firefox comes up with Feb 7 (maybe every week when it checks it assumes it's valid until the next check(?)).

Nevertheless, the correct fix is to not cache update.rdf files when an update of Firefox occurs, either automatically or when the user requests it, no matter what the server says.

(In reply to comment #9)
> (In reply to comment #8)
> > Also, it's not working on in all cases after 24 hours. In one profile on a
> > version of FF running on Windows, "Find Update" still reports it can't find the
> > update, well after 24 hours. Maybe the bug is more insidious than that.
> That would be a different bug and it would be a good thing if the uniqueness of
> that system were to be isolated so the cause could be found and then a bug
> filed for it.
> 

Comment 11

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

The testing I did on this showed that the update data will not be read from the cache after 24 hours and all of your other systems used the updated data per your own comment. Perhaps what you are experiencing on this one system is artificial in that the actions you are taking are causing it not to use the updated data, the system has settings that cause this to be different, etc.... what ever the case the right fix would be to have XMLHttpRequest to honor no-cache, etc. for the instances where this actually causes a problem (e.g. needing the update rdf datasource to not be read from the cache for those that are unable to wait the 24 hours).