Version: webkit2gtk3-2.25.92 Tested on Fedora 31 and ArchLinux. WebKit2 2.25.92 initial view loading is slow (epiphany, eolie, geary, ...) It is really visible in Geary (3.33.92 on Fedora and 3.32.2 on ArchLinux) where loading a mail hangs for some seconds. Looks like a regression.
Confirming, also an issue with 2.25.4 in current Ubuntu Eoan and the current nightly flatpak build. It's potentially quite visible in Geary because the WebKitWebView is a child of a GtkRevealer, which animates the height of the WebView. So maybe a layout/rendering issue? But also potentially a delay on WebKitWebContext construction, since Geary currently constructs a new one for each conversation. I'm thinking maybe the latter since I can't seem to see the delay opening a new tab in Ephy, but can catch it opening a new incognito window, and even new tabs in incognito windows - notice how the text caret in the location bar freezes blinking for a second when opening a new incognito tab?
Actually, seems I mis-remembered how it works, Geary actually constructs a single shared WebContext at startup and uses that, so perhaps the delay is in spawning the first WebProcess for a context?
Here what happens in Eolie: First test: - Launch eolie => load google.com - Open a new tab => slow => load google.com - Click on any link in google page - Open a new tab => fast => load google.com So, doing some navigation seems to fix the issue. Second test: - Modify Eolie to use a new context for every view - Doing some navigation does not fix the issue So, looks it's an issue with WebKitWebContext initial state.
I don't see any delay in ephy incognito windows. We used to spawn the web process when the web page was created, but now it's delayed until the first load. That might be the cause, but I can't reproduce it.
Can reproduce with epihany here: https://youtu.be/xr0OmMqq8g8 Fedora 31 with epiphany-3.33.92-1.fc31.x86_64 When I click on new tab button, there is a one second lag (like in Eolie) Launching stable epiphany from flathub => No lag
(In reply to Cédric Bellegarde from comment #5) > Can reproduce with epihany here: https://youtu.be/xr0OmMqq8g8 It doesn't happen here :-( > Fedora 31 with epiphany-3.33.92-1.fc31.x86_64 > > When I click on new tab button, there is a one second lag (like in Eolie) > > Launching stable epiphany from flathub => No lag Does it happen with MiniBrowser too?
Created attachment 378075 [details] Python browser with issue MiniBrowser does not load an URI by default so impossible to reproduce. Here a small python example. Click on WebKitGTK button => lag Click on Empty button => no log So, looks related to load_uri()
Why are you using an idle source to load the uri?
Oops, uploaded wrong version, was just some testing. You can remove the idle_add().
I can't reproduce it anyway with the test case.
Ok, I can reproduce it now, without the idle
The problem is that now we are always calling DrawingAreaProxy::waitForBackingStoreUpdateOnNextPaint() after a new process is launched and we used to do that only when launching a new process after a crash. This makes m_hasReceivedFirstUpdate useless, because it's always set to true right after a process is launched. Then, we wait up to half a second (which is usually the case for the initial load) until the first update. We only want to do that when recovering from a crash or when swapping processes to avoid flashing effect.
Created attachment 378183 [details] Patch
Created attachment 378184 [details] Rebased patch
Can confirm it fixed the issue in Eolie. For Geary, it's really better but there is a small delay when revealing a message (was not present with WebKitGTK 2.24).
(In reply to Cédric Bellegarde from comment #15) > Can confirm it fixed the issue in Eolie. > > For Geary, it's really better but there is a small delay when revealing a > message (was not present with WebKitGTK 2.24). I would need a way to reproduce it
Created attachment 378356 [details] Example using a Gtk revealer to show webview Ok, does not happen with this simple example so issue looks to be in Geary.
Comment on attachment 378184 [details] Rebased patch Looks good from my side. Let's wait for the ack of an owner
(In reply to Sergio Villar Senin from comment #18) > Comment on attachment 378184 [details] > Rebased patch > > Looks good from my side. Let's wait for the ack of an owner Chris?
Ping owners, please.
Comment on attachment 378184 [details] Rebased patch View in context: https://bugs.webkit.org/attachment.cgi?id=378184&action=review > Source/WebKit/UIProcess/WebPageProxy.h:1747 > + InitialProcess, You may need to make sure the current process is the dummy one to determine that it is really the initial process launch. > Source/WebKit/UIProcess/WebPageProxy.h:1749 > + Reload I think this should be "Crash", reloading is not a reason for launching a new process unless the previous process has crashed. > Source/WebKit/UIProcess/WebPageProxy.h:1752 > + void launchProcess(const WebCore::RegistrableDomain&, ProcessLaunchReason = ProcessLaunchReason::InitialProcess); Please do not specify a default parameter value and force call sites to specify the reason.
(In reply to Chris Dumez from comment #21) > Comment on attachment 378184 [details] > Rebased patch > > View in context: > https://bugs.webkit.org/attachment.cgi?id=378184&action=review > > > Source/WebKit/UIProcess/WebPageProxy.h:1747 > > + InitialProcess, > > You may need to make sure the current process is the dummy one to determine > that it is really the initial process launch. Well, it doesn't matter here if it's a delayed process launch. > > Source/WebKit/UIProcess/WebPageProxy.h:1749 > > + Reload > > I think this should be "Crash", reloading is not a reason for launching a > new process unless the previous process has crashed. Ok, makes sense, I followed the logic of WebPageProxy::launchProcessForReload > > Source/WebKit/UIProcess/WebPageProxy.h:1752 > > + void launchProcess(const WebCore::RegistrableDomain&, ProcessLaunchReason = ProcessLaunchReason::InitialProcess); > > Please do not specify a default parameter value and force call sites to > specify the reason. Ok.
Created attachment 378950 [details] Patch for landing
Committed r249953: <https://trac.webkit.org/changeset/249953>