[Webkit-unassigned] [Bug 216123] [GTK][WPE] WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD returned when plugins are disabled

Wed Sep 9 08:27:21 PDT 2020

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

--- Comment #8 from Carlos Garcia Campos <cgarcia at igalia.com> ---
(In reply to Michael Catanzaro from comment #7)
> I added debug. What happens with WebKit trunk is:
> 
> ** (epiphany:26619): WARNING **: 08:54:24.839: LOAD STARTED:
> https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/
> c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek
> 
> ** (epiphany:26619): WARNING **: 08:54:25.524: LOAD COMMITTED:
> https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/
> c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek
> 
> ** (epiphany:26619): WARNING **: 08:54:26.577: LOAD FAILED:
> https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/
> c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek
> 
> ** (epiphany:26619): WARNING **: 08:54:26.578: LOAD FINISHED:
> https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/
> c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek
> 
> ** (epiphany:26619): WARNING **: 08:54:26.582: LOAD STARTED:
> https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/
> c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek
> 
> ** (epiphany:26619): WARNING **: 08:54:26.591: LOAD COMMITTED:
> https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/
> c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek
> 
> ** (epiphany:26619): WARNING **: 08:54:26.592: LOAD FINISHED:
> https://gnome.modular.im/_matrix/media/r0/download/gnome.modular.im/
> c7fc680ae099cbd40063a50c81c944a9e26c4922/Peek
> 
> So: we start load, fail load, finish load, then do it all over. With
> WebKitGTK 2.29.92, WebKit displays the media controls, but the media
> controls are broken and unable to actually play the media due to bug
> #183259. That's the behavior we want to get back to. But with WebKitGTK
> trunk, Epiphany displays an error: "Plug-in handled load."

Yes, because you stopped handling that error in ephy.

> That's a WebKit
> error page, though, not the fancy Epiphany error page.

Yes, because you stopped handling that error in ephy, the default handler is called and it shows the default error page, because WebKit also stopped handling that error in the default handler.

> If I check out
> Epiphany commit
> https://gitlab.gnome.org/GNOME/epiphany/-/commit/
> 868de06fca4018bb5eaf61bed8dd8c952e813ec2 then I get the same with a fancy
> Epiphany error page. So just changing the error domain will not be enough to
> fix this bug, because something else is wrong inside WebKit. I tried this:

I meant adding a new error with the same code, but different domain, that needs to be handled by ephy. Ephy returns early if error domain is not network or policy, then it handles errors individually. If we add the new error to network or policy and ephy keeps current code just adding the new error it should just work.

> diff --git a/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
> b/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
> index 191007b6bb66..bb6c1618fbe5 100644
> --- a/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
> +++ b/Source/WebKit/UIProcess/API/glib/WebKitWebView.cpp
> @@ -470,7 +470,8 @@ void
> WebKitWebViewClient::didReceiveUserMessage(WKWPE::View&, UserMessage&& mess
>  static gboolean webkitWebViewLoadFail(WebKitWebView* webView,
> WebKitLoadEvent, const char* failingURI, GError* error)
>  {
>      if (g_error_matches(error, WEBKIT_NETWORK_ERROR,
> WEBKIT_NETWORK_ERROR_CANCELLED)
> -        || g_error_matches(error, WEBKIT_POLICY_ERROR,
> WEBKIT_POLICY_ERROR_FRAME_LOAD_INTERRUPTED_BY_POLICY_CHANGE))
> +        || g_error_matches(error, WEBKIT_POLICY_ERROR,
> WEBKIT_POLICY_ERROR_FRAME_LOAD_INTERRUPTED_BY_POLICY_CHANGE)
> +        || g_error_matches(error, WEBKIT_POLICY_ERROR,
> WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD))
>          return FALSE;
>  
>      GUniquePtr<char>
> htmlString(g_strdup_printf("<html><body>%s</body></html>", error->message));
> 
> But that wasn't enough to make it work.

Because the patch is wrong, you are using WEBKIT_POLICY_ERROR domains for the WEBKIT_PLUGIN_ERROR_WILL_HANDLE_LOAD error.

> I think desired behavior would be load started -> load committed -> load
> finished, once, without any errors. But on the other hand, I'm also aware
> that attempting to paper over internal WebKit loader behavior at the API
> level has caused very tricky bugs in the past, so it's probably risky to try
> changing that.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20200909/c26c65c7/attachment-0001.htm>