260073 2023-08-11 09:10:53 -0700 REGRESSION(2.41.90): Cannot scroll certain pages due to rendering failure, must switch to different tab to update rendering 2023-09-25 00:43:25 -0700 1 1 1 Unclassified WebKit WebKitGTK WebKit Nightly Build PC Linux RESOLVED FIXED https://bugs.webkit.org/show_bug.cgi?id=259264 https://bugs.webkit.org/show_bug.cgi?id=260146 https://bugs.webkit.org/show_bug.cgi?id=260446 P2 Normal --- 1 mcatanzaro cgarcia abrarsl2002 bugs-noreply cgarcia kdwkleung mcatanzaro pbryan two webkit-bug-importer xry111 oldest_to_newest 1970730 0 mcatanzaro 2023-08-11 09:10:53 -0700 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. 1970899 1 mcatanzaro 2023-08-12 07:17:33 -0700 Might or might not be a duplicate of bug #259264 1970900 2 mcatanzaro 2023-08-12 07:33:59 -0700 This bug does not occur when using WEBKIT_DISABLE_DMABUF_RENDERER=1 1970944 3 cgarcia 2023-08-13 06:05:01 -0700 Does it always happen? I can't reproduce it. 1970945 4 cgarcia 2023-08-13 06:06:32 -0700 Ok, I can reproduce with GTK4 only 1970963 5 mcatanzaro 2023-08-13 10:49:12 -0700 (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. 1971048 6 cgarcia 2023-08-14 09:46:13 -0700 Pull request: https://github.com/WebKit/WebKit/pull/16668 1972839 7 xry111 2023-08-22 20:45:48 -0700 Interestingly it no longer shows up in 2.41.91 despite the PR is not merged. 1972959 8 cgarcia 2023-08-23 06:52:35 -0700 (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 1973363 9 mcatanzaro 2023-08-24 15:00:45 -0700 (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. 1975818 10 mcatanzaro 2023-09-06 09:47:00 -0700 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. 1976632 11 mcatanzaro 2023-09-09 10:06:35 -0700 (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. :/ 1976949 12 pbryan 2023-09-11 16:09:46 -0700 *** Bug 260553 has been marked as a duplicate of this bug. *** 1976950 13 pbryan 2023-09-11 16:12:03 -0700 I too cannot get this to reproduce reliably, but it is still occurring today with WebKitGTK 2.41.92. 1976969 14 mcatanzaro 2023-09-11 17:01:18 -0700 *** Bug 259264 has been marked as a duplicate of this bug. *** 1976974 15 mcatanzaro 2023-09-11 17:08:09 -0700 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. 1977009 16 pbryan 2023-09-11 21:21:21 -0700 As others have noted, I too find it much easier to reproduce in Power Saver mode. 1977010 17 cgarcia 2023-09-11 22:07:45 -0700 I think https://github.com/WebKit/WebKit/pull/16668 fixes this. 1977034 18 cgarcia 2023-09-12 02:17:09 -0700 (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 1977036 19 cgarcia 2023-09-12 02:17:36 -0700 *** Bug 260446 has been marked as a duplicate of this bug. *** 1978967 20 mcatanzaro 2023-09-21 06:09:40 -0700 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. 1979125 21 two 2023-09-21 13:53:07 -0700 i don't have this on gnome-nightly any more 1979133 22 mcatanzaro 2023-09-21 14:12:01 -0700 That's because gnome-nightly has 2.42.0. This bug will return in 2.43. 1979744 23 cgarcia 2023-09-25 00:43:25 -0700 This will be fixed by #261673, no need to reopen.