FF 1.5.0.1 does not consult my update.rdf file

RESOLVED DUPLICATE of bug 318793

Status

()

Toolkit
Add-ons Manager
--
major
RESOLVED DUPLICATE of bug 318793
13 years ago
10 years ago

People

(Reporter: Godmar Back, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

13 years ago
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
I am quite sure you are seeing a cached version of the rdf data and I believe there is already a bug on that.
Whiteboard: [DUPEME]
btw: I believe it will find the new data in the rdf (e.g. not read it from the cache) within 24 hours.
(Reporter)

Comment 3

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

Comment 5

13 years ago
(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.

(Reporter)

Comment 6

13 years ago
(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.
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 ***
Status: UNCONFIRMED → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
Whiteboard: [DUPEME]
(Reporter)

Comment 8

13 years ago
(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.

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

Comment 10

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

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

Updated

10 years ago
Product: Firefox → Toolkit
You need to log in before you can comment on or make changes to this bug.