I think the api is general enough that should accommodate tool users (as it did in webkit1).
I think collecting "got-chunk" pieces and assembling them again is replicating what the code is already doing. Did you get any suggestions on alternative ways to do this ? Wrt frames, I am only looking for the raw frame html, as this is a subresource of the main_resource. And as such the raw frame html content could/should be exposed in the UI process (the subresource is there but the content is empty). I understand the separation between the UI and the network/web process but the devil is in the details. Is there any sample code of a specific web extension doing something useful ? On Thu, Aug 28, 2014 at 6:07 PM, Victor Lucero <[email protected]> wrote: > > Comments below > > El 28-08-2014, a las 11:51, Jose <[email protected]> escribió: > >> thanks, comments below >> >> On Thu, Aug 28, 2014 at 4:32 PM, Victor Lucero >> <[email protected]> wrote: >>> >>> 1)Got the actual data for all the resources been downloaded its a bit >>> tricky. in our case we use webkit_get_default_session() to access the soup >>> main session and attach a "request-queued” event into it so for each element >>> downloaded you could access the soup-message, and for each soup-message you >>> can attach "got-chunk” so every piece of data is send to that event and you >>> need to manually store it to get its length and contents- sadly this events >>> was removed in libsoup 2.39.4 if I remember well. but thanks that its open >>> source I patched that feature back (ugly but I was desperate) if you want i >>> cane send you that patch , its works in the latest version of lib soup used >>> by webkitgtk and webkit2gtk. >>> Sadly there is no element in the api to get or catch the frames that are >>> created in a webpage, the guys here told me to file a bug asking for this >>> feature in webkit2gtk but in the old API is present via the signal >>> “frame-created” over a web_view or frame. I think i will file that bug >>> because i need that functionality but im still working with the old API. >> >> This approach seems overly complicated but it may well be the only >> approach with webkit2. Please do send me >> the patch as it will help me learn a bit more about this. > > isn’t thaaat complicated. just attach some signals to the soup engine and > wait to the contents and store them for later use. > i attached the patch but remember this only bring back the “got-chunk” > functionality to the soup-message object of lib soup. it has nothing to do > directly with webkitgtk. > (the path its just the diff between the version of the file when the feature > was removed so this code isn mine ok?) > > >> >> I think we should get guidance from the webkit2gtk developers (most >> code I've looked at is written by Carlos G, >> and it's nicely crafted :)) >> >> I found that webkit1 had a wekit_web_view_get_subresources >> http://trac.webkit.org/changeset/143302 >> but it was removed for webkit2. I think something like that with a >> custom timeout to limit the caching of resources >> might be useful but there might be a better approach. >> >>> 2) the method and patch described in point 1 also works for all the elements >>> that pass throughout the browser so all the elementos downloaded by the >>> flash and the fly itself can be obtained :) >> >> Aha! This is then very useful. But still I think getting the >> subresources (in my case I collect them >> manually, via resource-load-started) should also include the frame raw >> content. The subresource >> seems to be there and the content is missing (unless I am missing something). >> >> Also, I wanted some guidance on how to approach this with the new plugin >> changes >> http://blogs.igalia.com/carlosgc/2014/08/06/gtk-3-plugins-in-webkitgtk-and-evince-browser-plugin/ >> >> I want to detect when a specific plugin loader is being called and the >> content file. >> > > > > >>> 3) how are you capturing these screenshots? We do screenshots accessing >>> Cairo but our tool make sure that the page is full loaded, also found that >>> some pages just crash the xlib if the page is too heavy and you don’t use a >>> scrollview to contain it. please, tell me more details about this issue. >> >> I do very basic stuff but it works nicely. Just check the testing code >> for how to use >> webkit_web_view_get_snaphsot. Crashing shouldn't be a problem with the >> new process model. >> >> Ping me offline if you need some ideas. >> >> >>> I hope this help >> >> yes definitely. _______________________________________________ webkit-gtk mailing list [email protected] https://lists.webkit.org/mailman/listinfo/webkit-gtk
