With 2.16.1 there are frequent issues on Wayland with a lot of pages that rendered correctly before. I can only give an example here and hope that someone can reproduce this. Weston + MiniBrowser 2.16.1 + MESA git 17.0-branchpoint-2613-g957ccbe + No X11 libraries (WKGTK+ Source w/ minor patches to the wayland backend and ANGLE to prevent inclusion of X11 header files) There is a distinct problem where the page becomes (GTKish window color) gray and is unresponsive. Moving the mouse cursor across MiniBrowser causes the gray to flicker back-and-forth to the supposed content, which however remains unresponsive. The UI otherwise is still responsive (navigating back to the previous page or refreshing has an effect, for example). Unfortunally, I can not reliably quote a page which reproduces this issue (for example the current Google "doodle" has this problem but will be gone soon). A page, which refuses to render though is for instance https://www.epson.de/products/see-through-mobile-viewer/moverio-bt-300 though it appears to be a different kind of behaviour. If I find any pages where one can reliably reproduce the first bug, I'll report them here.
We recently started getting complaints that YouTube does not render anything. I wonder if it is this same issue. (In reply to ManDay from comment #0) > A page, which refuses to render though is for instance > > https://www.epson.de/products/see-through-mobile-viewer/moverio-bt-300 > > though it appears to be a different kind of behaviour. Yes, I can reproduce this. It's totally white. I doubt rendering is the only problem here, though, because it also took astoundingly-long to load.
(In reply to Michael Catanzaro from comment #1) > We recently started getting complaints that YouTube does not render > anything. I wonder if it is this same issue. (Note: I can't reproduce on YouTube.)
(In reply to Michael Catanzaro from comment #2) > (In reply to Michael Catanzaro from comment #1) > > We recently started getting complaints that YouTube does not render > > anything. I wonder if it is this same issue. > > (Note: I can't reproduce on YouTube.) I can only reproduce it on the new YouTube design that can be enabled on youtube.com/testtube But it happens both with webkitgtk 2.16.1 and 2.14.1, so it's probably a different issue.
I can occasionally reproduce the "apparent freez w/ GTK gray" on this page https://itch.io/games/html5 though not through some reliable steps, in weston. Takes a bit of scrolling around and hovering over the elements. Behaviour is the same: MiniBrowser (apparently) freezes, resizing the window turns it all grey and sometimes, moving the mouse into certain areas causes it to flicker to the content and back to gray.
(In reply to exalm7659 from comment #3) > I can only reproduce it on the new YouTube design that can be enabled on > youtube.com/testtube > > But it happens both with webkitgtk 2.16.1 and 2.14.1, so it's probably a > different issue. Addition: And on X11 as well.
(In reply to exalm7659 from comment #3) > I can only reproduce it on the new YouTube design that can be enabled on > youtube.com/testtube > > But it happens both with webkitgtk 2.16.1 and 2.14.1, so it's probably a > different issue. Yes, bug #171603
I've found that the precise issue with a gray, unresponsive Webview happens quite reliably on Google Drive/Docs. That is, after I log in to "Google Drive" and choose "New > Google Docs > Empty document" one of the two windows fairly quickly goes gray. Maybe someone could give it a try on these pages and see whether or not it is stable for them.
With the recent unstalbe release 2.17.5 things got worse, but also easily reproducible now for me. In weston, I start MiniBrowser, navigate to http://www.zeit.de and drag the window larger towards the right by the right border. The new area is black and doesn't render properly (I suspect that's one example of a multitude of various symptoms seen in different WMs and on different webpages).
I've been testing a bit with current ToT and http://www.zeit.de, both with Wayland and Xorg, and both with AC enabled and disabled. I see that using Xorg, resizing the window is way more expensive than using Wayland. The window takes a while to be redrawn and so does the page, and the resize is sluggish. Using Wayland, both the window resize and the page redraw is smooth and fluent. This is the same both with and without AC, despite without AC everything is a bit smoother. I also found that with AC enabled, both in Xorg and Wayland, resizing the window several times can lead to a crash in the WebProcess. I'll try to find what's happening there.
> I also found that with AC enabled, both in Xorg and Wayland, resizing the > window several times can lead to a crash in the WebProcess. I'll try to find > what's happening there. It seems that the crash was related to https://bugs.webkit.org/show_bug.cgi?id=173866. I've tested with the patch proposed for that bug and I'm not able to reproduce the crash anymore. Regarding the rendering issues, I'm not able to reproduce them, besides the sluggish window resizing with Xorg. Can we retest this once 2.18 is released and see whether the problem is still there?
I've been playing with a test page ManDay sent me and I can easily reproduce a crash in the web process with it. I've looked a bit into it and I found that it's related to entering AC mode on demand. When loading the page, AC mode gets enabled. If the window is made bigger, the browser will exit AC mode, and if the window is made smaller again the browser will try to enter AC mode again and crash. I'll keep investigating. The crash can be avoided by using WEBKIT_DISABLE_COMPOSITING_MODE=1 or WEBKIT_FORCE_COMPOSITING_MODE=1, as both vars disable on demand AC.
I tried WEBKIT_DISABLE_COMPOSITING_MODE=1 and the issue is gone for me. It appears we are talking about the same thing now.
*** Bug 174480 has been marked as a duplicate of this bug. ***
Created attachment 318246 [details] Patch
Comment on attachment 318246 [details] Patch Good catch!
Comment on attachment 318246 [details] Patch Clearing flags on attachment: 318246 Committed r220793: <http://trac.webkit.org/changeset/220793>
All reviewed patches have been landed. Closing bug.
*** Bug 169184 has been marked as a duplicate of this bug. ***