Bug 254919 – [GTK] Sometimes image documents do not render in a new web view

• Status: RESOLVED
• Resolution: FIXED
• Component: WebKitGTK

[Michael Catanzaro]

Since upgrading Epiphany Tech Preview from 2.40.0 to 2.41.1, there is a new regression where sometimes web content does not load in a newly-created web view. I have not yet found a reproducer for this problem. Sometimes a Ctrl+R is enough to fix the web view, but sometimes the web view is broken until it's destroyed and recreated.

This may or may not be related to bug #254918.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #0)
> This may or may not be related to bug #254918.

This is indeed caused by bug #254918.

*** This bug has been marked as a duplicate of bug 254918 ***

[Michael Catanzaro]

Actually, sorry, I think we have two separate bugs that can trigger this. This is sometimes but not always associated with bug #254918.

[Michael Catanzaro]

Reproducer: right click on https://bugs.webkit.org/attachment.cgi?id=465934 and "open in new tab". The bug never occurs when opening the link in an existing tab, but almost always occurs when using a new tab.

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #3)
> Reproducer: right click on https://bugs.webkit.org/attachment.cgi?id=465934
> and "open in new tab". The bug never occurs when opening the link in an
> existing tab, but almost always occurs when using a new tab.

It doesn't happen here. Could you check if it happens with dmabuf renderer disabled?

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #4)
> It doesn't happen here. Could you check if it happens with dmabuf renderer
> disabled?

No, when using WEBKIT_DISABLE_DMABUF_RENDERER=1 this bug goes away. So at least we know that much.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #3)
> Reproducer: right click on https://bugs.webkit.org/attachment.cgi?id=465934
> and "open in new tab". The bug never occurs when opening the link in an
> existing tab, but almost always occurs when using a new tab.

Hm, it looks like the top row or two of pixels actually does get rendered. Could the vertical height be messed up?

[Michael Catanzaro]

OK, I finally noticed something important. If the only open tab in the browser is this page and you right click https://bugs.webkit.org/attachment.cgi?id=465934 and open it in a new tab, then it will always load properly. If you leave that tab open, right click again, open in new tab again, the second tab and all subsequently-opened tabs will be broken. If all tabs containing the image are closed, then opening it in a new tab will succeed again.

So the bug generally occurs when the image is already open in another tab.

This is not the only condition that triggers the bug (it happens in normal browsing, and I don't open the same page twice when browsing normally) but it should help with reproducing.

[Michael Catanzaro]

Here is the output of a debug patch you gave me. Initial page load:

$ jhbuild run ~/Projects/GNOME/install/libexec/webkitgtk-6.0/MiniBrowser https://bugs.webkit.org/show_bug.cgi?id=254919
DBG: [0x7fe06a010f40] AcceleratedBackingStoreDMABuf
DBG: [0x7fe06a010f40] AcceleratedBackingStoreDMABuf::realize fds: -1,-1
DBG: [0x7f5dde103d40] AcceleratedSurfaceDMABuf
DBG: [0x7fe06a010f40] AcceleratedBackingStoreDMABuf::update: 0 -> 11
DBG: [0x7f5dde103d40] AcceleratedSurface::hostResize: 0x0 -> 1024x691
DBG: [0x7f5dde103d40] AcceleratedSurfaceDMABuf::clientResize: 1024x691
DBG: [0x7fe06a010f40] AcceleratedBackingStoreDMABuf::configure: 1024x691

Now I click "open in new window" and the load succeeds:

DBG: [0x7fe06a011e40] AcceleratedBackingStoreDMABuf
DBG: [0x7f5dde1f0680] AcceleratedSurfaceDMABuf
DBG: [0x7fe06a011e40] AcceleratedBackingStoreDMABuf::update: 0 -> 15
DBG: [0x7fe06a011e40] AcceleratedBackingStoreDMABuf::realize fds: -1,-1
DBG: [0x7f5dde1f0680] AcceleratedSurface::hostResize: 0x0 -> 1024x691
DBG: [0x7f5dde1f0680] AcceleratedSurfaceDMABuf::clientResize: 1024x691
DBG: [0x7fe06a011e40] AcceleratedBackingStoreDMABuf::configure: 1024x691
DBG: [0x7f9cfe0ffdc0] AcceleratedSurfaceDMABuf
DBG: [0x7fe06a011e40] AcceleratedBackingStoreDMABuf::update: 15 -> 0
DBG: [0x7fe06a011e40] AcceleratedBackingStoreDMABuf::update: 0 -> 18
DBG: [0x7f9cfe0ffdc0] AcceleratedSurface::hostResize: 0x0 -> 1024x691
DBG: [0x7f9cfe0ffdc0] AcceleratedSurfaceDMABuf::clientResize: 1024x691
DBG: [0x7f5dde1f0680] ~AcceleratedSurfaceDMABuf
DBG: [0x7fe06a011e40] AcceleratedBackingStoreDMABuf::configure: 1024x691

Now I "open in new window" a second time and it fails to load:

DBG: [0x7fe06a012520] AcceleratedBackingStoreDMABuf
DBG: [0x7f5dde188380] AcceleratedSurfaceDMABuf
DBG: [0x7fe06a012520] AcceleratedBackingStoreDMABuf::update: 0 -> 22
DBG: [0x7fe06a012520] AcceleratedBackingStoreDMABuf::realize fds: -1,-1
DBG: [0x7f5dde188380] AcceleratedSurface::hostResize: 0x0 -> 1024x691
DBG: [0x7f5dde188380] AcceleratedSurfaceDMABuf::clientResize: 1024x691
DBG: [0x7fe06a012520] AcceleratedBackingStoreDMABuf::configure: 1024x691
DBG: [0x7fae760ffdc0] AcceleratedSurfaceDMABuf
DBG: [0x7fe06a012520] AcceleratedBackingStoreDMABuf::update: 22 -> 0
DBG: [0x7fe06a012520] AcceleratedBackingStoreDMABuf::update: 0 -> 25
DBG: [0x7f5dde188380] ~AcceleratedSurfaceDMABuf
DBG: [0x7fae760ffdc0] AcceleratedSurface::hostResize: 0x0 -> 1024x691
DBG: [0x7fae760ffdc0] AcceleratedSurfaceDMABuf::clientResize: 1024x691
DBG: [0x7fe06a012520] AcceleratedBackingStoreDMABuf::configure: 1024x691

Looks pretty similar. Do you want me to print the pointer values of the AcceleratedSurfaceDMABuf and AcceleratedBackingStoreDMABuf?

MiniBrowser behaves a bit differently than Epiphany. My comment #7 applies only to Epiphany. With MiniBrowser, it normally (but not always) fails to load on the first try, not the second try as shown above. Once it fails to load for the first try, all subsequent tries seem to fail.

[Carlos Garcia Campos]

I finally managed to reproduce it with GTK4, I was always trying with GTK3, that's why it didn't happen for me. So, for some reason it's specific to GTK4, and only happens with pson enabled, so looks related to that. I could also reproduce it with WEBKIT_DISABLE_DMABUF_RENDERER=1 so it's not a DMA-BUF regression, maybe it was the resize simplification.

[Carlos Garcia Campos]

I can reproduce with the resize simplification patches reverted too.

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #9)
> I could
> also reproduce it with WEBKIT_DISABLE_DMABUF_RENDERER=1 so it's not a
> DMA-BUF regression, maybe it was the resize simplification.

Weird, I've just tested this environment variable for a third time and I'm consistently unable to reproduce with the environment variable set. It really makes the difference for me.

[Carlos Garcia Campos]

Ok, I finally found the reason why opening a link to an image in new window causes the web view to be blank in GTK4. 

When the ImageDocument is created, the main frame visible size hasn't been set yet, so ImageDocument::scale is 0 causing ImageDocument::resizeImageToFit to use a 0x0 image.

The reason why the visible size is not set at that point is because the web view doesn't do any size-allocate before the web view is created, so the view size of the web page creation parameters is 0x0.

Once the size-allocate is done the UpdateGeometry message is sent. ImageDocument uses an event listener for dom widow resize events, to update the image when the main frame view is resized. However, the resize event is not emitted in this case, because the layout we do for the resize is the first one (or at least it's marked as such), so when LocalFrameView::scheduleResizeEventIfNeeded() is called LocalFrameView::willDoLayout has already set the current viewport size and scale, so it's considered as unchanged. For some reason this only happens with PSON enabled.

The reason why it only happens in GTK4 is because in GTK3 there's indeed a size-allocate before the web page is created, so it's created with the right size from the beginning, and ImageDocument creates the document structure with the right image size.

In any case, the ImageDocument should always be notified when the main frame view is resized, so maybe the dom window resize event is not the best way.

Any idea?

[Darin Adler]

Yes, I agree that the mistake here is using a DOM event listener for this. That’s for page content, not the web engine itself. I suggest looking at the other functions already called as part of resizing. This would primarily be a view function so I’d suggest looking at FrameView first.

[Michael Catanzaro]

We might have two different bugs here with the same symptoms. Carlos Garcia has debugged the problem with MiniBrowser. The problem with Epiphany is likely somewhat different.

[Carlos Garcia Campos]

(In reply to Michael Catanzaro from comment #14)
> We might have two different bugs here with the same symptoms. Carlos Garcia
> has debugged the problem with MiniBrowser. The problem with Epiphany is
> likely somewhat different.

They could be related, the fact that with GTK4 we don't have a size-allocate before the new page is created means that we have a 0x0 visible contents for a while. In any case, I'll try to reproduce the epiphany one with GTK4, because it doesn't seem to happen with GTK3.

[Carlos Garcia Campos]

Pull request: https://github.com/WebKit/WebKit/pull/14334

[Michael Catanzaro]

Carlos created bug #257324 to fix the Epiphany bug that I originally reported here. This bug is now for the confusingly-similar MiniBrowser issue.

[EWS]

Committed 264576@main (1e27b309b70c): <https://commits.webkit.org/264576@main>

Reviewed commits have been landed. Closing PR #14334 and removing active labels.