The nsILocalFile interface is the only one inheriting from nsIFile, and I believe every implementation of nsIFile in the Mozilla code also implements nsILocalFile. The separation of these two interfaces is probably more painful than it should be. This should be considered somewhat risky, as anything in the Mozilla code, or in extensions, dealing with file I/O could be affected. If we do this, we might want to keep the deprecated interface around for a little while so external developers can update their code bases.
Assignee: nobody → geoff
Status: NEW → ASSIGNED
Attachment #609045 - Flags: review?(benjamin)
Comment on attachment 609045 [details] [diff] [review] patch There is no need to change NS_LOCAL_FILE_CID, please don't. Please add [builtinclass] to nsIFile so that nobody tries to implement it in script. r=me with those changes.
Attachment #609045 - Flags: review?(benjamin) → review+
Would it be practical to add [deprecated] to nsILocalFile, as it is for nsIJSXMLHttpRequest? http://mxr.mozilla.org/mozilla-central/source/content/base/public/nsIXMLHttpRequest.idl#398
Perhaps later, but there are plenty of uses in the tree which would currently just spam warning noise for something harmless.
Comment on attachment 609045 [details] [diff] [review] patch I don't think you need my review for this, Benjamin's is sufficient.
Okay then, landed with those changes https://hg.mozilla.org/integration/mozilla-inbound/rev/82c7bdff95d4
Target Milestone: --- → mozilla14
This change should have very little compat risk for JS addons or recompiled C++ addons, but we should nevertheless note it in the "Firefox 14 for Developers" page and update the interface docs on MDC. Geoff is that something you can do?
Yes, I'll do that when I get time.
Status: ASSIGNED → RESOLVED
Last Resolved: 7 years ago
Resolution: --- → FIXED
Updated: https://developer.mozilla.org/en/Firefox_14_for_developers https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsILocalFile https://developer.mozilla.org/en/XPCOM_Interface_Reference/nsIFile (I've left the method descriptions on the nsILocalFile page for the time being to avoid duplication)
Just saw Geoff's post on dev-platform > In most cases running 'sed s/nsILocalFile\b/nsIFile/g' on your code will be > sufficient, although you might end up with pointless do_QueryInterface calls that > you should weed out. If that's the case, can we leave some sort of shim around so that add-on developers don't need to make any changes and binary compatibility is maintained? We typically find out about the impact of bugs that remove interfaces very late in the cycle, and backing out the change at that point requires a UUID change (which can hurt add-on compatibility even more).
Note that we did not remove the nsILocalFile interface, we merely moved all of its guts into nsIFile. So nsILocalFile *is* the shim, and AFAIK there are no plans to remove it any time soon so that JS extensions will continue to work. C++ extensions may require changes not from this bug but from bug 749930 where we're changing some classes to use nsIFile exclusively. But I don't think that there is any additional shimming that we need to do for extensions.
You need to log in before you can comment on or make changes to this bug.