Bug 260073 – REGRESSION(2.41.90): Cannot scroll certain pages due to rendering failure, must switch to different tab to update rendering

• Component: WebKitGTK
• Status: RESOLVED FIXED

[Michael Catanzaro]

With Ephy Tech Preview using WebKitGTK 2.41.90, right click this link to open it in a new tab:

https://github.com/WebKit/WebKit

Then try to scroll the page. Notice scrolling does not work at all. The scrolling actually happens, but the changes are not drawn unless you switch to a new tab and back again.

The bug doesn't seem to happen when loading the URL directly. Only happens when using the "open in new tab" action.

[Michael Catanzaro]

Might or might not be a duplicate of bug #259264

[Michael Catanzaro]

This bug does not occur when using WEBKIT_DISABLE_DMABUF_RENDERER=1

[Carlos Garcia Campos]

Does it always happen? I can't reproduce it.

[Carlos Garcia Campos]

Ok, I can reproduce with GTK4 only

[Michael Catanzaro]

(In reply to Carlos Garcia Campos from comment #3)
> Does it always happen?

I think it happens always.

Also, it seems to be some general performance issue rather than specific to scrolling. E.g. typing is also affected.

[Carlos Garcia Campos]

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

[Xi Ruoyao]

Interestingly it no longer shows up in 2.41.91 despite the PR is not merged.

[Carlos Garcia Campos]

(In reply to Xi Ruoyao from comment #7)
> Interestingly it no longer shows up in 2.41.91 despite the PR is not merged.

Yes because bug #260146 works around it

[Michael Catanzaro]

(In reply to Xi Ruoyao from comment #7)
> Interestingly it no longer shows up in 2.41.91 despite the PR is not merged.

So the original problem where this occurs reproducibly is indeed fixed, but I'm still hitting the problem quite regularly with 2.41.91, so it's definitely still broken. :( Unfortunately it seems to occur purely at random now. It's no longer reproducible after bug #260146.

[Michael Catanzaro]

Carlos found a reproducer: it breaks after a cross-origin navigation followed by a history navigation. Click any of the links to https://github.com in this bug report, then click Back, and the bug will occur.

[Michael Catanzaro]

(In reply to Michael Catanzaro from comment #10)
> Carlos found a reproducer: it breaks after a cross-origin navigation
> followed by a history navigation. Click any of the links to
> https://github.com in this bug report, then click Back, and the bug will
> occur.

Carlos fixed this via bug #261273. But unfortunately, although the rendering failure after history navigation is fixed, this general bug is still happening as of 2.41.92, so we're back to being unable to reproduce the problem. Honestly I do not think we're in good shape to release 2.42.0 currently. :/

[Paul Bryan]

*** Bug 260553 has been marked as a duplicate of this bug. ***

[Paul Bryan]

I too cannot get this to reproduce reliably, but it is still occurring today with WebKitGTK 2.41.92.

[Michael Catanzaro]

*** Bug 259264 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

So bug #259264 provides evidence that this broke prior to July 16 (thanks Kdwk!). And I'm moderately confident that 2.41.6 did not have this bug. So it likely broke somewhere in the 12-day span between July 4 and July 16.

My next assumption was that one of Carlos Garcia's graphics commits surely introduced this issue, so I went looking and found that he took a break during this timespan and landed zero pull requests during this time. Drat.

I will bisect bug #260446 next to see where it leads. It might be related to this one. Maybe. Can't think of anything else to try.

[Paul Bryan]

As others have noted, I too find it much easier to reproduce in Power Saver mode.

[Carlos Garcia Campos]

I think https://github.com/WebKit/WebKit/pull/16668 fixes this.

[Carlos Garcia Campos]

(In reply to Carlos Garcia Campos from comment #17)
> I think https://github.com/WebKit/WebKit/pull/16668 fixes this.

It doesn't fix it in all the cases and it's not the right fix. I've just disabled frame rate throttling in the stable branch. For main, we are already working on a new display refresh monitor implementation that will correctly handle the frame rate throttling. For the stable branch we'll see if we leave the workaround, find a solution or just backport the new display refresh.

https://github.com/WebKit/WebKit/commit/0b063c26d00ed38a6188033e64a0446004bfc665

[Carlos Garcia Campos]

*** Bug 260446 has been marked as a duplicate of this bug. ***

[Michael Catanzaro]

This was "fixed" on the 2.42 branch by https://github.com/WebKit/WebKit/commit/0b063c26d00ed38a6188033e64a0446004bfc665. I'm confident the problem is fully resolved in 2.42.

However, that is a stable branch commit that did not land on main. Is this really fixed on main? Reopening.

i don't have this on gnome-nightly any more

[Michael Catanzaro]

That's because gnome-nightly has 2.42.0. This bug will return in 2.43.

[Carlos Garcia Campos]

This will be fixed by #261673, no need to reopen.