I believe the problem is that a WebKit plugin cannot take ownership
of the WebFrame's WebDataSource. Plugins are expected to initiate
their own resource loads. WebFrame will cancel its WebDataSource
once the plugin view has been created.
Thanks,
-t
On Dec 8, 2005, at 5:20 PM, Rudi Sherry wrote:
Sorry this is a long post but I've been working on this a while and
it's complicated.
Also (while I'm apologizing), sorry for accidentally sending this
to cocoa-dev rather than webkitsdk-dev. I didn't mean to post it
there.
I have a Safari Cocoa Plug-in (Web Kit Plug-in, not Netscape plug-
in) and I'm running into something that I can't seem to get around.
My plug-in gets instantiated when the user navigates to a URL with
a certain mime type and the server starts sending the data.
When webPlugInStart is called for my plug-in, I need to get the
data for the URL. It's already being downloaded AFAIK: I get the
WebFrame containing my plug=in, and that has a WebDataSource that I
want to use (I'm not embedded, I'm the entire frame).
The question is, how do I get hold of that data and more
importantly, how do I know when the WebDataSource is finished
downloading? The documentation isn't that clear but seems to imply
that if [webDataSource isLoading]==NO && [webDataSource data]!
=null, then it's the entire contents... but that not what I'm seeing.
By the time I check the data source, perhaps three seconds have
gone by since the server started downloading the data.
If the data is short (~10K), [webDataSource isLoading]==NO, and
[webDataSource data]!=nil and is the entire data, and everything
works.
If the data is long (>100K), [webDataSource isLoading]==NO, and
[webDataSource data]!=nil, but the data is *not* the entire data;
it's a short snippet, sometimes in the middle of the resource being
sent down from the server, sometimes the beginning. I've seen the
length of that data (NSData) between 2K and 30K.
I thought maybe "isLoading==NO" meant it was in between loads, and
that I had to check the length of the data, waiting until it
matched [response expectedContentLength], so I created a timer proc
that fired every 2 seconds, checking the data again. No deal --
the length of [ webDataSource data ] never changed, nor did its
contents. It's as if it stopped trying as soon as I asked about it...
I used tcpdump and sure enough, only the first part of the data was
coming down -- then it stopped. I checked the server code and ran
a parallel plug-in under Windows (obviously not Cocoa) that sent
the same request, and the server always responded with the entire
file. So I was pretty confident it wasn't the server.
Then I thought maybe something on the Safari side was manually
stopping the loading, so I ran Safari under gdb and put breakpoints
at anything that said "stopLoading" (using 'info fun stopLoading'),
including some KHTML and WebDataSource(Private) stuff.
_stopLoading was being called, but inside the original [WebFrame
loadRequest:] call that is asking for the data in the first
place.... then an odd thing happened: when I continued from those
breakpoints, everything worked!
I found that if I went through this exercise under gdb and put a
breakpoint at -[WebDataSource(WebPrivate) _stopLoadingInternal] and
then continued when it got there, everything worked -- all the data
came down. If I ran it under gdb and didn't set the breakpoint, it
didn't work.
Obviously there is some kind of timing issue going on here, but I
can't figure out how to stop tickling it. Does anyone have any
suggestions?
Thanks,
Rudi Sherry
Adobe Systems Incorporated
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webkitsdk-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webkitsdk-dev/email@hidden
This email sent to email@hidden
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Webkitsdk-dev mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
http://lists.apple.com/mailman/options/webkitsdk-dev/email@hidden
