Alex Vincent [:WeirdAl] Reporter
	Description • 13 years ago

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.

	Benjamin Smedberg
	Comment 2 • 12 years ago

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.

	Alex Vincent [:WeirdAl] Reporter
	Comment 3 • 12 years ago

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

	Benjamin Smedberg
	Comment 4 • 12 years ago

Perhaps later, but there are plenty of uses in the tree which would currently just spam warning noise for something harmless.

	:Gavin Sharp [email: gavin@gavinsharp.com]
	Comment 5 • 12 years ago

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

I don't think you need my review for this, Benjamin's is sufficient.

	Geoff Lankow (:darktrojan) Assignee
	Comment 6 • 12 years ago

Okay then, landed with those changes
https://hg.mozilla.org/integration/mozilla-inbound/rev/82c7bdff95d4

	Benjamin Smedberg
	Comment 7 • 12 years ago

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?

	Geoff Lankow (:darktrojan) Assignee
	Comment 8 • 12 years ago

Yes, I'll do that when I get time.

	(no longer active)
	Comment 9 • 12 years ago

https://hg.mozilla.org/mozilla-central/rev/82c7bdff95d4

	Geoff Lankow (:darktrojan) Assignee
	Comment 10 • 12 years ago

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)

	Alex Keybl [:akeybl]
	Comment 11 • 12 years ago

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

	Benjamin Smedberg
	Comment 12 • 12 years ago

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.