Note: There are a few cases of duplicates in user autocompletion which are being worked on.

access nsIDOMFileInternal in xpcom extension

VERIFIED FIXED in mozilla1.9.3a3

Status

()

Core
Drag and Drop
VERIFIED FIXED
8 years ago
7 years ago

People

(Reporter: Jan Gerber, Assigned: Jan Gerber)

Tracking

({dev-doc-complete, verified1.9.2})

Trunk
mozilla1.9.3a3
dev-doc-complete, verified1.9.2
Points:
---

Firefox Tracking Flags

(status1.9.2 .2-fixed)

Details

(Whiteboard: [evang-wanted-3.6])

Attachments

(3 attachments, 4 obsolete attachments)

(Assignee)

Description

8 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2b2pre) Gecko/20091105 Namoroka/3.6b2pre
Build Identifier: 

i want to allow drag and drop of files in my extension.
to do this i have a function in my extension that gets passed nsIDOMFile
via an api exposed to the page(global constructor)

boolean drop(in nsIDOMFile file);

and try to get nsIDOMFileInternal
 var internal = file.QueryInterface(Components.interfaces.nsIDOMFileInternal);

this fails.

there should be a way to get the local path inside of an xpcom component.


Reproducible: Always
I'll bet you can do this today somehow.  Adding some people who might know how.
Yeah, I don't think there's currently a way to get to the inner file from script. It's always scary making internal interfaces accessible on public objects because of the way that XPConnect works. Anytime you QI, the functions are permanently added to the object and so exposed to web pages.

Generally you can't make use of the functions, but it's still scary to rely on. And it alters the object in ways that could potentially break pages.

At least that is how it used to be. In this new world of wrappers everywhere things might be different.


There's still a few things we could do though:

* Make .name return the full path if the caller has chrome privileges. This is
  how inputElement.value works.
* Add a function on windowutils that returns the nsIFile inside a nsIDOMFile.
* Maybe something else through the magic of wrappers.
(Assignee)

Comment 3

8 years ago
returning the full path in case caller has chrome privileges in .name sounds like a good solution to me.
Yeah, the simpler the solution here, the better, I think.

Also, confirming based on comment 2.
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Assignee)

Comment 5

8 years ago
has anyone looked into exposing full path in name in the privileged case?
(Assignee)

Comment 6

8 years ago
so i went ahead and changed nsIFile to return the full path,
however someting else changed and my extension no longer works,

in the idl file, dropFile is specified like this:
  boolean dropFile(in nsIDOMFile file);

in javascript its called like this:
dropContainer.addEventListener("drop", function (event) {
  var dt = event.dataTransfer,
  files = dt.files;
  if(files.length >= 1) {
    var ext = new Myextension();
    alert(files[0].name);
    ext.dropFile(files[0]);
  }
  event.stopPropagation();
  event.preventDefault();
}, false);

this now thows an exception:

Error: uncaught exception: [Exception... "Cannot find interface information for parameter arg 0 [myextension.dropFile]"  nsresult: "0x80570006 (NS_ERROR_XPC_CANT_GET_PARAM_IFACE_INFO)"  location: "JS frame :: file:///test/drop.html :: anonymous :: line 34"  data: no]

at the time i created this bug, dropFile was called and an nsIDOMFile was passed to it.
(Assignee)

Comment 7

8 years ago
Created attachment 420606 [details] [diff] [review]
patch to return full path if IsCallerTrustedForCapability("UniversalFileRead")
Please file a separate bug on the problem in comment 6. It seems unrelated to this bug.

As for the patch, the more I think about it, the more I think that it'd be better to have a separate property that exposed the full path. This both has the advantage that the path-less filename is still easily accessible, and would keep the API more consistent.

Call the new property .mozFullPath or something like that. And make it return the empty string if the caller doesn't have UniversalFileAccess
(Assignee)

Comment 9

8 years ago
Created attachment 420671 [details] [diff] [review]
add readonly attribute DOMString mozFullPath

add new attribute mozFullPath to nsIDOMFile:

readonly attribute DOMString mozFullPath;

returns full path if nsContentUtils::IsCallerTrustedForCapability("UniversalFileRead")
otherwise it returns an empy string.
Attachment #420606 - Attachment is obsolete: true
(Assignee)

Comment 10

8 years ago
Created attachment 420672 [details] [diff] [review]
add readonly attribute DOMString mozFullPath

attach the right patch.
Attachment #420671 - Attachment is obsolete: true
Comment on attachment 420672 [details] [diff] [review]
add readonly attribute DOMString mozFullPath

You need to call

aFileName.Truncate()

when returning the empty string. To ensure that if aFileName was non-empty when the function is called it's still the empty string when we return.

r/sr=me with that fixed.
Attachment #420672 - Flags: superreview+
Attachment #420672 - Flags: review+
(Assignee)

Comment 12

8 years ago
Created attachment 420702 [details] [diff] [review]
add readonly attribute DOMString mozFullPath

add aFileName.Truncate(); to patch
Attachment #420672 - Attachment is obsolete: true
Comment on attachment 420702 [details] [diff] [review]
add readonly attribute DOMString mozFullPath

Crap, I forgot that you need to update the interface iid. But I can do that before checking in.

Thanks for the patch!
Attachment #420702 - Flags: superreview+
Attachment #420702 - Flags: review+
(Assignee)

Comment 14

8 years ago
any idea which version of firefox this will be availalbe?
Assignee: nobody → j
j@oil21.org: What's your name, so that I can add your proper name to the checkin

:)
(Assignee)

Comment 16

8 years ago
(In reply to comment #15)
> j@oil21.org: What's your name, so that I can add your proper name to the
> checkin
> 
> :)
that would be Jan Gerber

Comment 17

8 years ago
(In reply to comment #14)
> any idea which version of firefox this will be availalbe?

That would probably be the next Firefox version after 3.6.x, Firefox 3.7 or 4.0. It's hard to tell because the schedule changes. This could get in to 3.6.(1/2) I guess, though, if we ask specifically for it. What do say, Jonas?
Whiteboard: [evang-wanted-3.6]
(Assignee)

Comment 18

8 years ago
blame sicking, says Axel.
(Assignee)

Updated

8 years ago
Keywords: checkin-needed
Would be great if someone could write up a patch for 1.9.2 as well. It needs to not change any existing interfaces, but instead add the property to a new nsIDOMFile_1_9_2_BRANCH interface. That way we can fix this in firefox 3.6 as well.

Comment 20

8 years ago
Created attachment 428174 [details] [diff] [review]
Patch 1_9_2_BRANCH
Attachment #428174 - Flags: review?

Updated

8 years ago
Attachment #428174 - Flags: review? → review?(jonas)
You need to also add the interface here:

http://mxr.mozilla.org/mozilla-central/source/dom/base/nsDOMClassInfo.cpp#3571

r=me with that fixed

Comment 22

8 years ago
Created attachment 428178 [details] [diff] [review]
Patch 1_9_2_BRANCH with classInfo
Attachment #428174 - Attachment is obsolete: true
Attachment #428178 - Flags: review?(jonas)
Attachment #428174 - Flags: review?(jonas)
Comment on attachment 428178 [details] [diff] [review]
Patch 1_9_2_BRANCH with classInfo

This is needed for extensions to be able to use some of the new File APIs we added in Firefox 3.6. Specifically, this will allow extensions to go get the full path of a DOMFile in order to access it directly using normal gecko or OS file APIs.

It's been baking a while on trunk and should be very safe.
Attachment #428178 - Flags: review?(jonas)
Attachment #428178 - Flags: review+
Attachment #428178 - Flags: approval1.9.2.2?
Clearing checkin-needed as it looks like everything reviewed and approved has been checked in.  If I'm incorrect please set checkin-needed again and make it clearer what needs to be checked in.
Keywords: checkin-needed
Comment on attachment 428178 [details] [diff] [review]
Patch 1_9_2_BRANCH with classInfo

a1922=beltzner
Attachment #428178 - Flags: approval1.9.2.2? → approval1.9.2.2+
Checked in to 1.9.2.2

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ad92ebff4d0c
status1.9.2: --- → .2-fixed
For the record, this seems to have caused a 3% regression on Ts Dirty Profile tests; not sure it requires backing out, but thought you'd like to know.
Wait - it doesn't make any sense for this to have caused that regression. Ignore comment 27, please.
http://hg.mozilla.org/mozilla-central/rev/6d13028da120
Status: NEW → RESOLVED
Last Resolved: 7 years ago
OS: Linux → All
Hardware: x86 → All
Resolution: --- → FIXED
Target Milestone: --- → mozilla1.9.3a3
Verified on trunk and 1.9.2 with the testcase I will attach shortly.

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a4pre) Gecko/20100321 Minefield/3.7a4pre ID:20100321123434

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2.3pre) Gecko/20100321 Namoroka/3.6.3pre ID:20100321033650

It also needs an update on MDC.
Status: RESOLVED → VERIFIED
Keywords: dev-doc-needed, verified1.9.2
Version: unspecified → Trunk
Created attachment 434071 [details]
test (enhanced previlegies)
(Assignee)

Comment 32

7 years ago
also made an example page using the new feature with Firefogg at 
http://firefogg.org/examples/drop/
Documentation updated: https://developer.mozilla.org/en/DOM/File
Keywords: dev-doc-needed → dev-doc-complete
You need to log in before you can comment on or make changes to this bug.