RESOLVED FIXED 260073
REGRESSION(2.41.90): Cannot scroll certain pages due to rendering failure, must switch to different tab to update rendering 
https://bugs.webkit.org/show_bug.cgi?id=260073
Summary REGRESSION(2.41.90): Cannot scroll certain pages due to rendering failure, mu...
Michael Catanzaro
Reported 2023-08-11 09:10:53 PDT
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.
Attachments
Add attachment proposed patch, testcase, etc.
Michael Catanzaro
Comment 1 2023-08-12 07:17:33 PDT
Might or might not be a duplicate of bug #259264
Michael Catanzaro
Comment 2 2023-08-12 07:33:59 PDT
This bug does not occur when using WEBKIT_DISABLE_DMABUF_RENDERER=1
Carlos Garcia Campos
Comment 3 2023-08-13 06:05:01 PDT
Does it always happen? I can't reproduce it.
Carlos Garcia Campos
Comment 4 2023-08-13 06:06:32 PDT
Ok, I can reproduce with GTK4 only
Michael Catanzaro
Comment 5 2023-08-13 10:49:12 PDT
(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
Comment 6 2023-08-14 09:46:13 PDT
Pull request: https://github.com/WebKit/WebKit/pull/16668
Xi Ruoyao
Comment 7 2023-08-22 20:45:48 PDT
Interestingly it no longer shows up in 2.41.91 despite the PR is not merged.
Carlos Garcia Campos
Comment 8 2023-08-23 06:52:35 PDT
(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
Comment 9 2023-08-24 15:00:45 PDT
(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
Comment 10 2023-09-06 09:47:00 PDT
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
Comment 11 2023-09-09 10:06:35 PDT
(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
Comment 12 2023-09-11 16:09:46 PDT
*** Bug 260553 has been marked as a duplicate of this bug. ***
Paul Bryan
Comment 13 2023-09-11 16:12:03 PDT
I too cannot get this to reproduce reliably, but it is still occurring today with WebKitGTK 2.41.92.
Michael Catanzaro
Comment 14 2023-09-11 17:01:18 PDT
*** Bug 259264 has been marked as a duplicate of this bug. ***
Michael Catanzaro
Comment 15 2023-09-11 17:08:09 PDT
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
Comment 16 2023-09-11 21:21:21 PDT
As others have noted, I too find it much easier to reproduce in Power Saver mode.
Carlos Garcia Campos
Comment 17 2023-09-11 22:07:45 PDT
I think https://github.com/WebKit/WebKit/pull/16668 fixes this.
Carlos Garcia Campos
Comment 18 2023-09-12 02:17:09 PDT
(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
Comment 19 2023-09-12 02:17:36 PDT
*** Bug 260446 has been marked as a duplicate of this bug. ***
Michael Catanzaro
Comment 20 2023-09-21 06:09:40 PDT
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.
two
Comment 21 2023-09-21 13:53:07 PDT
i don't have this on gnome-nightly any more
Michael Catanzaro
Comment 22 2023-09-21 14:12:01 PDT
That's because gnome-nightly has 2.42.0. This bug will return in 2.43.
Carlos Garcia Campos
Comment 23 2023-09-25 00:43:25 PDT
This will be fixed by #261673, no need to reopen.
Note You need to log in before you can comment on or make changes to this bug.