160714 - nsIWindowWatcher Open Window from Stream.

Status: RESOLVED INCOMPLETE

(Core Graveyard :: Embedding: APIs, defect)

Description

[Doug Turner (:dougt)]

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?

Comment 1

[Stephane Saux]

cc rogc. This pertains to the 1Meg limit we ran into.

Comment 2

[Roger Chickering]

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.

Comment 3

[Doug Turner (:dougt)]

Attachment: 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.

Comment 4

[Judson Valeski]

roger: maybe you're seeing http://bugzilla.mozilla.org/show_bug.cgi?id=157144 ?

Comment 5

[Roger Chickering]

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.

Comment 6

[Darin Fisher]

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?

Comment 7

[Doug Turner (:dougt)]

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 8

[Dan M]

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).

Comment 9

[Doug Turner (:dougt)]

did you read my response to these security "concerns"?

Comment 10

[rpotts (gone)]

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

Comment 11

[Doug Turner (:dougt)]

to default owner to figure out how to support this functionality.

Comment 12

[Roger Chickering]

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!!!

Comment 13

[Benjamin Smedberg]

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.