The default bug view has changed. See this FAQ.

Merge nsILocalFile and nsIFile interfaces

RESOLVED FIXED in mozilla14

Status

()

Core
XPCOM
RESOLVED FIXED
6 years ago
5 years ago

People

(Reporter: WeirdAl, Assigned: darktrojan)

Tracking

({addon-compat, arch, dev-doc-needed})

Trunk
mozilla14
addon-compat, arch, dev-doc-needed
Points:
---
Dependency tree / graph
Bug Flags:
in-testsuite -
in-litmus -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

(Reporter)

Description

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

Comment 1

5 years ago
Created attachment 609045 [details] [diff] [review]
patch
Assignee: nobody → geoff
Status: NEW → ASSIGNED
(Assignee)

Updated

5 years ago
Blocks: 739001
(Assignee)

Updated

5 years ago
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+
(Reporter)

Comment 3

5 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
Perhaps later, but there are plenty of uses in the tree which would currently just spam warning noise for something harmless.
(Assignee)

Updated

5 years ago
Attachment #609045 - Flags: superreview?(gavin.sharp)
Comment on attachment 609045 [details] [diff] [review]
patch

I don't think you need my review for this, Benjamin's is sufficient.
Attachment #609045 - Flags: superreview?(gavin.sharp)
(Assignee)

Comment 6

5 years ago
Okay then, landed with those changes
https://hg.mozilla.org/integration/mozilla-inbound/rev/82c7bdff95d4
Flags: in-testsuite-
Flags: in-litmus-
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?
Keywords: addon-compat, dev-doc-needed
(Assignee)

Comment 8

5 years ago
Yes, I'll do that when I get time.
https://hg.mozilla.org/mozilla-central/rev/82c7bdff95d4
Status: ASSIGNED → RESOLVED
Last Resolved: 5 years ago
Resolution: --- → FIXED
(Assignee)

Comment 10

5 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)
Keywords: dev-doc-needed
(Assignee)

Updated

5 years ago
Blocks: 749930
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).
Keywords: dev-doc-needed
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.