Bug 171161

Summary: [GTK] Crash of WebProcess with on-demand AC
Product: WebKit Reporter: ManDay <manday>
Component: WebKitGTKAssignee: Miguel Gomez <magomez>
Status: RESOLVED FIXED    
Severity: Normal CC: alicem, bugs-noreply, cgarcia, commit-queue, magomez, mcatanzaro
Priority: P2    
Version: WebKit Nightly Build   
Hardware: Unspecified   
OS: Unspecified   
See Also: https://bugs.webkit.org/show_bug.cgi?id=171205
Attachments:
Description Flags
Patch none

Description ManDay 2017-04-22 02:52:03 PDT
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.
Comment 1 Michael Catanzaro 2017-04-22 06:34:35 PDT
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.
Comment 2 Michael Catanzaro 2017-04-22 06:34:58 PDT
(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.)
Comment 3 Alice Mikhaylenko 2017-05-03 05:52:32 PDT
(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.
Comment 4 ManDay 2017-05-03 06:25:00 PDT
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.
Comment 5 Alice Mikhaylenko 2017-05-03 06:52:40 PDT
(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.
Comment 6 Michael Catanzaro 2017-05-03 09:48:11 PDT
(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
Comment 7 ManDay 2017-05-14 02:29:37 PDT
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.
Comment 8 ManDay 2017-07-27 02:45:10 PDT
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).
Comment 9 Miguel Gomez 2017-08-09 07:01:48 PDT
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.
Comment 10 Miguel Gomez 2017-08-10 01:26:54 PDT
> 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?
Comment 11 Miguel Gomez 2017-08-11 02:09:20 PDT
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.
Comment 12 ManDay 2017-08-11 02:25:32 PDT
I tried WEBKIT_DISABLE_COMPOSITING_MODE=1 and the issue is gone for me. It appears we are talking about the same thing now.
Comment 13 Miguel Gomez 2017-08-16 00:51:52 PDT
*** Bug 174480 has been marked as a duplicate of this bug. ***
Comment 14 Miguel Gomez 2017-08-16 02:39:48 PDT
Created attachment 318246 [details]
Patch
Comment 15 Carlos Garcia Campos 2017-08-16 03:17:57 PDT
Comment on attachment 318246 [details]
Patch

Good catch!
Comment 16 WebKit Commit Bot 2017-08-16 04:26:42 PDT
Comment on attachment 318246 [details]
Patch

Clearing flags on attachment: 318246

Committed r220793: <http://trac.webkit.org/changeset/220793>
Comment 17 WebKit Commit Bot 2017-08-16 04:26:44 PDT
All reviewed patches have been landed.  Closing bug.
Comment 18 Miguel Gomez 2017-08-31 00:34:54 PDT
*** Bug 169184 has been marked as a duplicate of this bug. ***