Closed Bug 647653 Opened 10 years ago Closed 10 years ago

It should be possible to create nsIDOMBlob in JavaScript XPCOM components

Categories

(Core :: XPCOM, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla8

People

(Reporter: j, Assigned: khuey)

Details

(Keywords: dev-doc-complete, Whiteboard: fixed-in-bs)

Attachments

(2 files)

User-Agent:       Mozilla/5.0 (X11; Linux i686; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: 

It would be nice to be able to return nsIDOMBlob objects or implement nsIDOMBlob inside a custom xpcom element for an extension to make files/data available inside the DOM. i.e. like this:
 f = Cc["@mozilla.org/file/local;1"].createInstance(Ci.nsILocalFile);
 f.initWithPath(..);
 f.QueryInterface(Ci.nsIDOMBlob)

Right now there is no way to create an nsIDOMBlob from an nsILocalFile.
Trying to implement a Javascript XPCOM element with nsIDOMBlob interface was also seams to be impossbile since i.e nsIPartialFileInputStream is not abailable:

 Cc["@mozilla.org/network/partial-file-input-stream;1"]
   .createInstance(Ci.nsIPartialFileInputStream);

Its is also not quite clear how one could add a moz-filedata: url to implement
getInternalUrl in Kavascript.



Reproducible: Always
ongoing attempt to implement nsIDOMBlob in a JavaScript component,
it does not seam to call my getInternalUrl function. 
[Exception... "Component returned failure code: 0x804b000a (NS_ERROR_MALFORMED_URI) [nsIDOMFileReader.readAsBinaryString]" nsresult: "0x804b000a (NS_ERROR_MALFORMED_URI)"]

even if getInternalUrl would be called, it does not seam to be possible to add url to 
nsFileDataProtocolHandler from Javascript,
namely calling:
 nsFileDataProtocolHandler::AddFileDataEntry(url, this, aPrincipal);
Yes, accept Bug 607114 would have nicer syntax :-)
Status: UNCONFIRMED → RESOLVED
Closed: 10 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 607114
We didn't do this for components ... maybe we should.
Status: RESOLVED → REOPENED
Ever confirmed: true
Resolution: DUPLICATE → ---
This shouldn't be too hard to do, but I don't know if I should be adding the code to nsXPConnect::InitClasses, nsXPConnect::InitClassesWithNewWrappedGlobal, or both.

Blake?
On IRC, I floated the idea of just using a contract ID for this. But as that would be awkward, the answer to Kyle's question is that you need to add it to both.

You do need to be a little careful that you don't add it to Windows or ChromeWindows, though... I can't think of a clean way of doing that off the top of my head without checking the JSClass's name field :-/

Another option that might be cleaner would be to figure out a way to add the constructor in mozJSComponentLoader, the way that we add atob and dump to components' global objects.
Was any decision made how to move this forward?
(In reply to comment #8)
> Was any decision made how to move this forward?

Yeah, it should be pretty straightforward to add a constructor to the JS component loader.  I just need to sit down and do it.
Attached patch PatchSplinter Review
Assignee: nobody → khuey
Status: REOPENED → ASSIGNED
Attachment #542950 - Flags: review?(mrbkap)
Comment on attachment 542950 [details] [diff] [review]
Patch

Review of attachment 542950 [details] [diff] [review]:
-----------------------------------------------------------------

::: js/src/xpconnect/loader/mozJSComponentLoader.cpp
@@ +260,5 @@
> +        return JS_FALSE;
> +    }
> +
> +    nsCOMPtr<nsIXPConnect> xpc =
> +        do_GetService(kXPConnectServiceContractID, &rv);

Why not use nsXPConnect::GetXPConnect()?

@@ +272,5 @@
> +        XPCThrower::Throw(NS_ERROR_UNEXPECTED, cx);
> +        return JS_FALSE;
> +    }
> +
> +    JSObject* glob = JS_GetGlobalForObject(cx, scope);

You can just use JS_GetGlobalForScopeChain here.

@@ +278,5 @@
> +    nsCOMPtr<nsIXPConnectJSObjectHolder> holder;
> +    jsval retval;
> +    rv = xpc->WrapNativeToJSVal(cx, glob, native, nsnull,
> +                                &NS_GET_IID(nsISupports),
> +                                PR_FALSE, &retval, nsnull);

It looks like your passing PR_FALSE for aAllowWrapping. I think that should be PR_TRUE.
Attachment #542950 - Flags: review?(mrbkap) → review+
(In reply to comment #11)
> Comment on attachment 542950 [details] [diff] [review] [review]
> Patch
> 
> Review of attachment 542950 [details] [diff] [review] [review]:
> -----------------------------------------------------------------
> 
> ::: js/src/xpconnect/loader/mozJSComponentLoader.cpp
> @@ +260,5 @@
> > +        return JS_FALSE;
> > +    }
> > +
> > +    nsCOMPtr<nsIXPConnect> xpc =
> > +        do_GetService(kXPConnectServiceContractID, &rv);
> 
> Why not use nsXPConnect::GetXPConnect()?

Oh hey, that's neat.

> @@ +272,5 @@
> > +        XPCThrower::Throw(NS_ERROR_UNEXPECTED, cx);
> > +        return JS_FALSE;
> > +    }
> > +
> > +    JSObject* glob = JS_GetGlobalForObject(cx, scope);
> 
> You can just use JS_GetGlobalForScopeChain here.

That's neat too.

> @@ +278,5 @@
> > +    nsCOMPtr<nsIXPConnectJSObjectHolder> holder;
> > +    jsval retval;
> > +    rv = xpc->WrapNativeToJSVal(cx, glob, native, nsnull,
> > +                                &NS_GET_IID(nsISupports),
> > +                                PR_FALSE, &retval, nsnull);
> 
> It looks like your passing PR_FALSE for aAllowWrapping. I think that should
> be PR_TRUE.

ok.
http://hg.mozilla.org/mozilla-central/rev/e6220bfcfd17
Status: ASSIGNED → RESOLVED
Closed: 10 years ago10 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Target Milestone: --- → mozilla8
Am I correct that the change here is that you can now do "new File" in chrome code to create a DOM File object?
You can do new File in component scopes to create a DOM File object.  This has worked in chrome window scopes previously.
So how do you create an nsIDOMBlob object...?

Something like Cc["@mozilla.org/files/blob;1"].createInstance(Ci.nsIDOMBlob, [oFileBody], { type: "text/xml"});?

Thanks.
Are you sure...?

I'm pretty sure I have to use XPCOM stuff...

[21:22:41.674] ReferenceError: Blob is not defined @ resource://gre/modules/XPIProvider.jsm -> jar:file:///Users/main/Library/Application%20Support/Firefox/Profiles/xfm2tq4r.default/extensions/jid0-AaE9xBnbY78IjyBB6jwVpaKiyKQ@jetpack.xpi!/bootstrap.js -> resource://gre/modules/commonjs/toolkit/loader.js -> resource://jid0-aae9xbnby78ijybb6jwvpakiykq-at-jetpack/s12chung/lib/main.js:32
funny. someone just answered it on stackoverflow: http://stackoverflow.com/questions/19780396/use-blob-on-firefox-add-on

thanks for getting back so quickly though :). happy monday.
Oh ... that's some weird SDK thing then.
You need to log in before you can comment on or make changes to this bug.