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

[bugzilla-daemon at webkit.org]

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

Milan Crha <mcrha at redhat.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |INVALID

--- Comment #15 from Milan Crha <mcrha at redhat.com> ---
Hrm, this is embarrassing. It seems I made my initial tests incorrectly and the issue is not on the WebKitGTK+ side. I've still applied the latest patch in my local checkout of the WebKitGTK+ from git, thus I can connect to both "document-loaded" and "frame-loaded" signals (the later is that added in my patch). I added debug prints into both handlers and into the WebkitWebView's "load-event" signal, to see when is delivered what. I also artificially slowed down subframe generations, thus there is a time for the system to receive the signals when needed. The result shows this sequence:

   WebView::load-event WEBKIT_LOAD_STARTED
   WebView::load-event WEBKIT_LOAD_COMMITTED
      WebPage::document-loaded
      WebPage::frame-loaded
      WebPage::frame-loaded
      ....
      WebPage::frame-loaded
   WebView::load-event WEBKIT_LOAD_FINISHED

and that's all.

It shows three things:
1) the WebPage::document-loaded is delivered when the main frame is loaded,
   but without the sub-iframe-s being available
2) the WebPage::frame-loaded is emitted before the UI part knows about
   the load finished
3) the WebView::load-event with WEBKIT_LOAD_FINISHED is received only after
   all the subframes are fully loaded

That means that my statement from comment #0 is false, it's not a "matter of luck", it's more likely that I made something wrong in the Evolution.

Maybe the WebPage::frame-document-loaded could be found useful for someone in the future, but, as you indicated, you are trying not to expose frames in both the UI and the Web processes, then it's not needed to be added as of now, because the Evolution would not use it anyway (it'll use the 3) from the above, which it already does, though it can be that it does so in some odd way and it needs fixing on the Evolution side, not on the WebKitGTK+ side).

I'm closing this due to these new findings. I'm sorry for the false noise. I'd not bother you, if I do my testing correctly at the first place. Thank you for your time.

-- 
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/20160603/a7aab213/attachment.html>