969 bytes, patch
|Details | Diff | Splinter Review|
3.55 KB, patch
|Details | Diff | Splinter Review|
596 bytes, text/plain
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.
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.
has anyone looked into exposing full path in name in the privileged case?
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
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.
Created attachment 420672 [details] [diff] [review] add readonly attribute DOMString mozFullPath attach the right patch.
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.
Created attachment 420702 [details] [diff] [review] add readonly attribute DOMString mozFullPath add aFileName.Truncate(); to patch
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!
any idea which version of firefox this will be availalbe?
firstname.lastname@example.org: What's your name, so that I can add your proper name to the checkin :)
(In reply to comment #15) > email@example.com: What's your name, so that I can add your proper name to the > checkin > > :) that would be Jan Gerber
(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?
blame sicking, says Axel.
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.
Created attachment 428174 [details] [diff] [review] Patch 1_9_2_BRANCH
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
Created attachment 428178 [details] [diff] [review] Patch 1_9_2_BRANCH with classInfo
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.
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.
Comment on attachment 428178 [details] [diff] [review] Patch 1_9_2_BRANCH with classInfo a1922=beltzner
Checked in to 18.104.22.168 http://hg.mozilla.org/releases/mozilla-1.9.2/rev/ad92ebff4d0c
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.
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:22.214.171.124pre) Gecko/20100321 Namoroka/3.6.3pre ID:20100321033650 It also needs an update on MDC.
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