There are many cases when the embedder has the data that they want to display in a new window. You could use a data url, but a deadlock will occur if the data url has more than 1mb of data. We should fix this deadlock, but the point of the matter is that creating a data url is totally insane for this kind of thing! The embeder shouldn't have to buffer all of their content then pass it as a string to Gecko. Unfortunately, I do not think that there is better way to create new window if you already have the data. :-( Show me the way if i missed something. To fix this, I want the window watcher to be able to accept a nsIInputStream when opening a new window. Adding a new interface which has this method would be ideal: nsIDOMWindow openWindowFromStream(in nsIDOMWindow aParent, in nsIInputStream aStream, in string aName, in string aFeatures, in nsISupports aArguments); This new interface would be qi'able from the current nsIWindowWatcher. Is there anything else that we know about today that this new interface should contain?
cc rogc. This pertains to the 1Meg limit we ran into.
We could just stream the data in using a custom nsIChannel, except that in our experience this has the problem that when you click on a link while the data is being streamed in the data stops, even if we try using a custom nsIURIContentListener::OnStartURIOpen to intercept the navigations. There's also a performance hit associated with the nsIChannel approach; we've noticed a delay when first loading a document that we don't see with the data URLs.
Created attachment 94953 [details] [diff] [review] patch v.1 Adds a new interface (nsIWindowWatcher2) which allows the creation of a new window based on a stream. I have not tested openWindowFromStream() yet.
roger: maybe you're seeing http://bugzilla.mozilla.org/show_bug.cgi?id=157144 ?
Jud: that bug doesn't sound quite the same. We were seeing a delay of 1-2 seconds when first loading the URL; it seems impossible that we could go that long without processing a paint event.
dougt: why not just invent a new protocol handler implementation to accompany the nsInputStreamChannel? something like "moz-stream://<some-opaque-string>" otherwise, we're going to have all these wierd origin problems, right? you'll presumably have nsIURIs getting created based on the stream name (or something) and what will that mean? it just seems to me that it would be a lot cleaner to do this with a new, special-case protocol handler. afterall, we already have a channel for this sort of thing, so why not a general protocol handler to boot?
creating a moz-stream: protocol is not as simple for the embedder as just passing a input stream off. maybe we could make it easier by building a generic service that would return a string url when given a nsIInputStream. When accessed this string url, system would know how to match the URL up to the given inputstream. I don't know, but this just seams kinda lame. What is an example of the security problems you forsee. The docshell already knows that the content is streaming and the URI is set to "internal:load-stream".
Comment on attachment 94953 [details] [diff] [review] patch v.1 Not ready for an r= because of Darin's observations. But if we do decide to go this route, note that there's a problem in the patch at the @@ -742,9 chunk. newDocShell->LoadStream will only be called if (!uriToLoad) but that can't happen (see line 728 of the unpatched file).
did you read my response to these security "concerns"?
i'm with darin... i think we should focus on making it easy for embeddors to use our current model -- ie. passing channels. rather than trying to tack something else on the side -- after all, under the covers we would just wrap the input stream with an input stream channel anyways. why don't we focus on Roger's issues with the input stream channel? in particular why there is a percievable delay using the channel. i believe that any data being streamed when a link is clicked will ALWAYS be canceled -- that's because we stop network activity when a link is clicked. to avoid this, need to figure out how to treat the streaming data as 'content activity' rather than network activity... that's because 'content activity' stops when new data arrives -- not when the request is issued. in either case, i think that we need to understand why the data needs to continue streaming... so we can get the best results. -- rick
to default owner to figure out how to support this functionality.
My app is working fine now with nsIChannel. No need for more work on this bug on my account. Thanks for all your help, everybody!!!
Marking a bunch of bugs in the "Embedding: APIs" component INCOMPLETE in preparation to archive that component. If I have done this incorrectly, please reopen the bugs and move them to a more correct component as we don't have "embedding" APIs any more.