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.
Might or might not be a duplicate of bug #259264
This bug does not occur when using WEBKIT_DISABLE_DMABUF_RENDERER=1
Does it always happen? I can't reproduce it.
Ok, I can reproduce with GTK4 only
(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.
Pull request: https://github.com/WebKit/WebKit/pull/16668
Interestingly it no longer shows up in 2.41.91 despite the PR is not merged.
(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
(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.
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.
(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. :/
*** Bug 260553 has been marked as a duplicate of this bug. ***
I too cannot get this to reproduce reliably, but it is still occurring today with WebKitGTK 2.41.92.
*** Bug 259264 has been marked as a duplicate of this bug. ***
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.
As others have noted, I too find it much easier to reproduce in Power Saver mode.
I think https://github.com/WebKit/WebKit/pull/16668 fixes this.
(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
*** Bug 260446 has been marked as a duplicate of this bug. ***
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
That's because gnome-nightly has 2.42.0. This bug will return in 2.43.
This will be fixed by #261673, no need to reopen.