Closed Bug 314270 Opened 20 years ago Closed 17 years ago

Spot changes to install.rdf files and load metadata

Categories

(Toolkit :: Add-ons Manager, enhancement)

Product:
Toolkit
Component:
Add-ons Manager
Platform:
x86
Windows XP
Type:
enhancement
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED WONTFIX

People

(Reporter: mossop, Unassigned)

References

Details

I have a couple of extensions (ones I am developing) installed with the text-file-in-the-extensions-dir trick. Since they are my extensions I always have the most recent version there, but generally firefox doesnt notice that the install.rdf has changed and so thinks I have the version it used to be rather than what it currently is. When I check for extension updates firefox finds what it thinks are updates to the extensions and displays a dialog to install the update, even though the local version has an equal or newer version in its install.rdf. It strikes me that if other applications for instance are using this method to install extensions into firefox then firefox should notice when they are updated. It's also somewhat annoying from a developer point of view that I keep getting asked to install newer versions of extensions that I already have.
So what you seem to be saying is that Firefox isn't verifying the local version numbers before looking at remote ones, but rather simply going by what it was told when installed? It seems to me that this would be a useful thing to check, but for the time being you could simply `update' locally by editing your jar and then dragging to the extension manager when you want to have the updates recognised (as you probably already do).
The only application managed installs are of the win32 registry type instal. What you are doing is short-circuiting the process by essentially managing an EM install yourself so the EM isn't involved and the data isn't updated. I agree it would be nice but I see this as an edge case. Also, if an app wanted to update an EM managed install it could use the extension dir xpi drop method which would allow the EM to manage the install and thereby update the data. btw: I think that if you 'touch' the pointer file or the dir it points to that the EM will update the data but I am not positive about this.
Dave - instead of just modifying the install.rdf make a copy of the file or delete it and create a new one in order to simulate an install. This will change the last modified time on the dir and it will update the data in the extensions datasource. This handles all cases except when the install.rdf is modified and you want it to automatically update the extensions datasource. As is we detect last modified changes to the dir in order to know when the data should reload and the one instance where this would fail is when the install.rdf data has been modified. To solve this we would have to detect changes to both the install.rdf and the dir which I believe would be more trouble and additional overhead than it is worth for this scenario. The only case I can think of that this affects is the extension developer that modifies an install.rdf without adding / deleting any files and a workaround is to touch the dir which can be done any number of ways (e.g. touch utility, copy a file in the dir, delete a file in the dir, etc.). With all of these things in mind I think this is wontfix unless someone can point out something I've overlooked.
A couple of quick experiments: Changing the time or recreating the pointer file has no effect. Adding files, removing files, changing files and renaming files has no effect. The only thing that gets Firefox to update the extension is to change the modified time on the dir, but right now the only way I have figured to do that is with cygwin which doesnt fit so well into my development process ;) out of interest, why use the dir's modified time to signal a reinstall when a reinstall really only updates the metadata from install.rdf?
(In reply to comment #4) > The only thing that gets Firefox to update the extension is to change the > modified time on the dir, but right now the only way I have figured to do that > is with cygwin which doesnt fit so well into my development process ;) This probably has to do with the way the OS handles changes to the filesystem... on WinXP / NTFS a copy or a delete of a file within the ext. dir changed the dir's last modified time for me whereas modifying a file does not. > out of interest, why use the dir's modified time to signal a reinstall when a > reinstall really only updates the metadata from install.rdf? Not sure what you are saying here... a reinstall installs everything with what was there when it was first installed... the last modified time on the dir tells the EM that there has been a change no matter what operation is the outcome. Also, checking the install.rdf instead of the dir would require getting a ref to the dir (e.g. it currently enumerates the extensions dir) and then the install.rdf which would be added overhead.
btw: it is kind of funny that you filed this when you did... I ran into a similar thing a couple of days ago though it was in the profile's extensions dir and not using a file pointer. This is when I found that copying or deleting a file WFM and I verified it last night after reading this bug when using a file pointer.
(In reply to comment #5) > This probably has to do with the way the OS handles changes to the > filesystem... on WinXP / NTFS a copy or a delete of a file within the ext. dir > changed the dir's last modified time for me whereas modifying a file does not. Ah right, my extension is on a FAT32 partition and nothing seems to change the dir time on that.
(In reply to comment #7) > Ah right, my extension is on a FAT32 partition and nothing seems to change the > dir time on that. An EM managed install does update the metadata in the extensions datasource so this only applies to the ext. dev senario you proposed. In thinking on this the only real concern I have that would make this bug something that should be fixed is if the app update doesn't change the last modified time for the app provided extensions which I haven't verified one way or the other though I suspect may be the case. Since the enumeration has to occur on every startup I would still prefer to have app update changed to fix this in order to avoid any startup time penalty for the code that would be needed to do this. This bug would be nice to have as long as there is no startup cost from it.
*** Bug 323208 has been marked as a duplicate of this bug. ***
Adding my voice in for this bug to be fixed. It should not be WONTFIXed, it is a valid bug, and should be fixed. IMHO checking the modified datetime for profile.rdf would require such incredibly little overhead that it's worth doing, for the sake of nice and easy extension/theme development and just generally ensuring that Firefox is working with current, not old, data - especially when that current data is available locally! Remember that this is a one-off operation, it's not exactly happening every 2 seconds, only on startup. I don't think the overhead difference would be noticable to a human. Maybe to Cmdr. Data.
The problem with increasing the startup time is that there are several parts of the application that would like to add to the startup time so it must be managed. This bug has never been reported by a normal user and the only time it affects anyone afaict is in regards to extension authors while working on their extension which is an extremely small - though important - subset of the user base.
It sounds like the best resolution on this is then a configuration setting that an extension author can turn on while they're developing. Can we please get that as a good compromise?
As usual, patches are always welcome.
(In reply to comment #12) > It sounds like the best resolution on this is then a configuration setting that > an extension author can turn on while they're developing. Can we please get > that as a good compromise? > Well, I think you can just disable extension information caching if you really want that. My argument would be that FF should really do this by default as it just ensures that old data isn't being used and I really find it hard to believe that checking a few modified datetimes will add much to the startup, especially with hard drives increasing in speed and the promise of persistent RAM-based storage.
It will add to startup, I have benchmarked it, and it is significant enough that it isn't acceptable along the same lines as disabling the xul cache by default wouldn't be acceptable. Also as previously noted, this only happens when developing an extension so there is no worry about it affecting anyone except when they are developing an extension in place. As a matter of fact, this is the way it is in 1.5 and there have been no reports of this happening except when developing an extension in place and I have verified that this is the case. I am not adverse to this being controlled by a pref that defaults to the current behavior when the pref is not present but I am too busy with 2.0 bugs to take this on at this time. Patches are welcome.
(In reply to comment #15) > It will add to startup, I have benchmarked it, and it is significant enough > that it isn't acceptable along the same lines as disabling the xul cache by > default wouldn't be acceptable. Heh. They were just have a discussion on Slashdot the other day about whether it was still worth using native code these days, instead of interpreted or bytecode, because machines were getting so fast it was becoming a non-issue. I found this comment particularly telling: http://ask.slashdot.org/comments.pl?sid=188271&cid=15522816 Whilst I understand this is an I/O issue rather than a processing one, the same general principle applies. I just can't understand why you're having a problem with a few ms of extra startup time, which will pretty much be guaranteed to decrease the faster systems get. The added functionality outweighs the cost easily, and you're being picky.
(In reply to comment #16) > The added functionality outweighs the cost easily, and you're being picky. What added functionality? Are you referring to that extension authors that are using Windows and not using NTFS for their file system would be able to develop extensions in place without having to perform an extra step so the install.rdf is read again and keeping in mind that the chrome.manifest is read? This sure seems like an edgecase that affects an extremely small group of people to me. There is also a couple of simple workarounds. Take a look at other bugs regarding Ts and other tinderboxen tests to see how ms's count.
(In reply to comment #17) > (In reply to comment #16) > > The added functionality outweighs the cost easily, and you're being picky. > What added functionality? Are you referring to that extension authors that are > using Windows and not using NTFS for their file system would be able to > develop I use Windows w/ NTFS, and when you modify install.rdf, it doesn't modify any directory's modified datetime. Point ignord. > This sure > seems like an edgecase that affects an extremely small group of people to me. > There is also a couple of simple workarounds. Simple but irritating. And, guess what, I still say the benefit outweighs the cost, because the cost is *SO* low.
How low is the cost?
I've added a new bug, bug #345708, that simply proposes getting rid of the install.rdf cacheing system. I think it would be a simpler solution than the one proposed here and the performance hit would be negligible.
*** Bug 345708 has been marked as a duplicate of this bug. ***
(In reply to comment #19) > How low is the cost? > How am I supposed to find out exactly? Do you think I'm a powerful Firefox developer that can check modified code in to see how it changes the tinderbox compile times? Doing it on my own system is pointless as different compile options / compiler / OS / hardware would clearly change the startup time of my version. The cost of checking the modified datetime of 10-20 install.rdf's is, I'm sure, very low.
It's also dependent on OS and hardware. The only sane way to test the performance impact would be to do it relative to the other tinderbox builds, which would mean somebody checking the modified code in to see the difference.
(In reply to comment #22 and comment #23) > How am I supposed to find out exactly? Do you think I'm a powerful Firefox > developer that can check modified code in to see how it changes the tinderbox > compile times? Doing it on my own system is pointless as different compile > options / compiler / OS / hardware would clearly change the startup time of my > version. No, I expect that if you make a statement that the cost is very low that you can back it up with before and after numbers from your development system.
(In reply to comment #24) > No, I expect that if you make a statement that the cost is very low that you > can back it up with before and after numbers from your development system. > You're making the reverse statement. You back your statement up with numbers from your development system.
I evaluated this and came up with numbers when this bug was first filed. If *YOU* want this fixed as you have suggested *YOU* will now need to take the time as *I* once did to prove your statement of "...because the cost is *SO* low." Otherwise you are just creating noise.
I found a work around for bug I orginally posted as Bug 427242 (it was marked a duplicate) my problem was my toolbar worked find with FF 3.0 beta 4, how ever did not work with beta 5, even though I set em:maxVersion="3.0b5" in my install.rfd. I was tring to test with beta 5 using a toolbar development environment. my work around is as follows. 1) create an xpi 2) create a new FF profile 3) start the new profile 4) install the xpi 5) the xpi install is blocked becuase of non trust site 6) press the ??okay??? to add to list of trusted sites 7) finish xpi install now my toolbar works with both my toolbar development environment and the new profile does anyone know how to foward this recipe to the people that maintain the "how to develop addons" web pages
Product: Firefox → Toolkit
I'm closing this out as it isn't something I'd expect us to take in its current form. We could potentially think about debugging prefs that developers could set that force a refresh of the datasource on every startup, but this is not something there is any drive to work on at this time.
Status: NEW → RESOLVED
Closed: 17 years ago
Resolution: --- → WONTFIX
You need to log in before you can comment on or make changes to this bug.