<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><span class="vcard"><a class="email" href="mailto:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span> changed
<a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Provide frame-related load signals in WebKitWebView"
href="https://bugs.webkit.org/show_bug.cgi?id=157899">bug 157899</a>
<br>
<table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>What</th>
<th>Removed</th>
<th>Added</th>
</tr>
<tr>
<td style="text-align:right;">Attachment #279764 Flags</td>
<td>review?, commit-queue?
</td>
<td>review-, commit-queue-
</td>
</tr></table>
<p>
<div>
<b><a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Provide frame-related load signals in WebKitWebView"
href="https://bugs.webkit.org/show_bug.cgi?id=157899#c14">Comment # 14</a>
on <a class="bz_bug_link
bz_status_NEW "
title="NEW - [GTK] Provide frame-related load signals in WebKitWebView"
href="https://bugs.webkit.org/show_bug.cgi?id=157899">bug 157899</a>
from <span class="vcard"><a class="email" href="mailto:cgarcia@igalia.com" title="Carlos Garcia Campos <cgarcia@igalia.com>"> <span class="fn">Carlos Garcia Campos</span></a>
</span></b>
<pre>Comment on <span class=""><a href="attachment.cgi?id=279764&action=diff" name="attach_279764" title="proposed patch IV">attachment 279764</a> <a href="attachment.cgi?id=279764&action=edit" title="proposed patch IV">[details]</a></span>
proposed patch IV
View in context: <a href="https://bugs.webkit.org/attachment.cgi?id=279764&action=review">https://bugs.webkit.org/attachment.cgi?id=279764&action=review</a>
Sorry, I forgot about this new patch. I don't think this is what we want though, see my comments below
<span class="quote">> Source/WebKit2/WebProcess/InjectedBundle/API/gtk/WebKitWebPage.cpp:60
> + FRAME_LOADED,</span >
I don't think this belongs here. This could makes sense in the UI process where we don't expose frames, but in the web extensions API we have WebKitFrame, so there's no reason for adding frame related signals to the page object. One of the reasons why we didn't want to expose frames was because we had a lot of signals duplicated in web view and frame, making it confusing. The web view signals actually meant main frame events, so we had two ways of getting events for the main frame. I agree we would be making the same mistake again here if we add document-loaded signal to WebKitFrame. Fortunately in the web extensions API we only have one signal related to the frame, document-loaded, so maybe we can deprecate it and add a new one that receives the frame. Or deprecated it, and move it to WebKitFrame (I know we only have API to get the main frame yet, but we could add frame-created signal or something like that).
<span class="quote">> Source/WebKit2/WebProcess/InjectedBundle/API/gtk/WebKitWebPage.cpp:186
> + g_signal_emit(WEBKIT_WEB_PAGE(clientInfo), signals[FRAME_LOADED], 0, toImpl(frame)->coreFrame()->document()->url().string().utf8().data());</span >
This is not frame-loaded, this should be frame-document-loaded or document-loaded-in-frame and it should receive a WebKitFrame, not a document URL.
<span class="quote">> Tools/TestWebKitAPI/Tests/WebKit2Gtk/TestWebExtensions.cpp:81
> + const char* frame_uri = nullptr;</span >
frame_uri -> frameURI
<span class="quote">> Tools/TestWebKitAPI/Tests/WebKit2Gtk/WebExtensionTest.cpp:139
> +static void frameLoadedCallback(WebKitWebPage* webPage, const gchar* frame_uri, WebKitWebExtension* extension)</span >
Ditto.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>