[Webkit-unassigned] [Bug 157899] [GTK] Provide frame-related load signals in WebKitWebView

Tue May 24 23:59:58 PDT 2016

https://bugs.webkit.org/show_bug.cgi?id=157899

--- Comment #11 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to comment #10)
> (In reply to comment #9)
> > That's indeed not the right way to do it. The web extension should emit a
> > signal when document loaded happens instead of relying on web view load
> > events that have nothing to do with dom bindings.
> 
> I am currently at commit 33e641672d5a84a0 of a webkit git master checkout,
> the `git log` says: "REGRESSION (r200638): -[DOMHTMLVideoElement play]
> disappeared from ObjC bindings" and at the end "git-svn-id:
> http://svn.webkit.org/repository/webkit/trunk@201212
> 268f45cc-cd09-0410-ab3c-d52691b4dbfc".
> 
> I modified evolution's code to check these things in a way that there is
> loaded a page with one iframe, (and the frame is a plain html), thus at the
> end the structure looks roughly like this:
>   <html>
>   <body>
>      <iframe src="..."></iframe>
>   </body>
>   </html>
> 
> and the load of the iframe content is done asynchronously, where I added a 5
> seconds delay to make things easier. The result of my debug prints is:
> 
> web_view_load_changed_cb: 42305544881 started (pid:19619)
>    web_page_document_loaded_cb: 42305558657 (pid:19653)
>      > mail_request_process_mail_sync: 42305561698 waiting for 5 seconds
> (pid:19619)
>      > mail_request_process_mail_sync: 42310561790 done wait for 5 seconds
> (pid:19619)
> web_view_load_changed_cb: 42310582854 finished (pid:19619)
> 
> where the very long number is a result of g_get_monotonic_time () (in
> microseconds) and the pid 19653 is my web-extension (WebProcess), while the
> pid 19619 is the evolution itself (UI process).
> 
> It shows that the web page's document-loaded signal (caught by
> web_page_document_loaded_cb) doesn't count with sub-frames and claims the
> page being loaded as soon as the main frame is populated.

Yes, we know it, as I said before we would need new API to cover other frames.

> Your proposal to add WebKitFrame::document-loaded signal doesn't scale,
> because:
> a) I cannot connect to one central place, but should connect to the
> WebKitFrame instances;
> b) How do I know that a frame instance had been created?
> c) should I traverse the DOM several times to know whether a new frame had
> been added or not? That's quite inefficient and requires a complex code to
> maintain.

It was not actually a proposal, just an idea, the details of the new API is what we should discuss here.

> > The UI process should wait for the document-loaded signal to allow the user
> > click on that button, or send a message to the extension, and the extension
> > should queue it until document-loaded happens.
> 
> See the debug prints above, it would still not work, because the
> WebKitPage::document-loaded signal is called when the inner frame content is
> not ready yet.

I haven't said the current API allows to do what you need, my only point is that if we need to add new API for your use case it has to be added to the web extensions API and not the UI process. What API specifically is something to be defined and your input here would help a lot. The way we usually do this is sending an email to the mailing list explaining the use case in detail, and proposing a possible API.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160525/57c45826/attachment.html>