Bug 174287 – On systems with smaller memory, bigger sites just render as one big white screen

• Component: Layout and Rendering
• Status: NEW

[Dan Jacobson]

Created attachment 314909 [details]
epiphany

On systems with smaller memory, bigger sites just render as one big white screen in many webkit based browsers.

If one moves the mouse over the page, link previews still show up in the corner, meaning that there are things underneath the mouse, it is just that the user cannot see them because the whole page is white.

I tried
dpkg: warning: downgrading libwebkit2gtk-4.0-37:i386 from 2.17.4-1 to 2.16.5-1
dpkg: warning: downgrading libjavascriptcoregtk-4.0-18:i386 from 2.17.4-1 to 2.16.5-1
dpkg: warning: downgrading libcairo-gobject2:i386 from 1.14.10-1 to 1.14.8-1
dpkg: warning: downgrading libcairo2:i386 from 1.14.10-1 to 1.14.8-1
but that didn't fix it.

There is no problem on systems faster systems with more memory.
I suppose it is some kind of race condition.
If rendering doesn't complete during a certain time, it just gives up.

[Dan Jacobson]

Created attachment 314910 [details]
midori

[Dan Jacobson]

Kernel: Linux 4.11.0-1-686-pae (SMP w/1 CPU core)

Package: epiphany-browser
Version: 3.22.7-1
Versions of packages epiphany-browser depends on:
ii  dbus-x11 [dbus-session-bus]  1.11.14-1
ii  epiphany-browser-data        3.22.7-1
ii  gsettings-desktop-schemas    3.24.0-1
ii  iso-codes                    3.75-1
ii  libavahi-client3             0.6.32-2
ii  libavahi-common3             0.6.32-2
ii  libavahi-gobject0            0.6.32-2
ii  libc6                        2.24-12
ii  libcairo2                    1.14.10-1
ii  libgcr-base-3-1              3.20.0-5.1
ii  libgcr-ui-3-1                3.20.0-5.1
ii  libgdk-pixbuf2.0-0           2.36.5-3
ii  libglib2.0-0                 2.53.3-1
ii  libgnome-desktop-3-12        3.22.2-1
ii  libgtk-3-0                   3.22.16-1
ii  libjavascriptcoregtk-4.0-18  2.17.4-1
ii  libnotify4                   0.7.7-2
ii  libpango-1.0-0               1.40.6-1
ii  libpangocairo-1.0-0          1.40.6-1
ii  libsecret-1-0                0.18.5-3.1
ii  libsoup2.4-1                 2.56.0-2
ii  libsqlite3-0                 3.19.3-2
ii  libwebkit2gtk-4.0-37         2.17.4-1
ii  libx11-6                     2:1.6.4-3
ii  libxml2                      2.9.4+dfsg1-3
ii  libxslt1.1                   1.1.29-2.1

Package: midori
Version: 0.5.12~wk2-exp1
Versions of packages midori depends on:
ii  libatk1.0-0                  2.22.0-1
ii  libc6                        2.24-12
ii  libcairo-gobject2            1.14.10-1
ii  libcairo2                    1.14.10-1
ii  libgck-1-0                   3.20.0-5.1
ii  libgcr-base-3-1              3.20.0-5.1
ii  libgcr-ui-3-1                3.20.0-5.1
ii  libgdk-pixbuf2.0-0           2.36.5-3
ii  libglib2.0-0                 2.53.3-1
ii  libgtk-3-0                   3.22.16-1
ii  libjavascriptcoregtk-4.0-18  2.17.4-1
ii  libp11-kit0                  0.23.7-2
ii  libpango-1.0-0               1.40.6-1
ii  libpangocairo-1.0-0          1.40.6-1
ii  libsoup2.4-1                 2.56.0-2
ii  libsqlite3-0                 3.19.3-2
ii  libwebkit2gtk-4.0-37         2.17.4-1
ii  libx11-6                     2:1.6.4-3
ii  libxml2                      2.9.4+dfsg1-3
ii  libxss1                      1:1.2.2-1
ii  libzeitgeist-2.0-0           0.9.16-0.2+b1

[Dan Jacobson]

Downgrading dependencies to two months back didn't help.
In midori https://www.facebook.com/tg.taiwan/ fully loads... then disappears.
The CPU meter keeps running though.
In epiphany -i https://www.facebook.com/tg.taiwan/ loading finishes (refresh icon appears), but we never see anything. The CPU meter stops too.

[Michael Catanzaro]

Possible dup of bug #173768 ("[GTK] Some web pages disappear immediately after rendering")? Does it happen on any websites that don't have videos?

[Dan Jacobson]

I don't think it is an exact duplicate.
I think it is related to how much memory the computer has.
All sites open fine when one has lots of memory.
But without lots of memory, using /usr/lib/i386-linux-gnu/webkit2gtk-4.0/MiniBrowser ,
http://google.com/ works.
http://maps.google.com/ is just white from start to finish.
http://www.openstreetmap.org/ is also just white.

My only alternative is to use non-webkit based browsers. But chromium takes too long to do anything. So I guess I won't be using this computer for much anymore.

However I also see exact behavior mentioned with https://devswag.com/products/classic-rust-t-shirt .

But http://midori-browser.org/ works fine.

[Carlos Alberto Lopez Perez]

How much memory your system has?

Does setting the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1 before starting the browser helps?

[Dan Jacobson]

> How much memory your system has?
KiB Mem :   499312 total (500 MB, half a gig.)
> Does setting the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1 before starting the browser helps?
Holy smokes Batman, you just saved me USD$1000 in new equipment purchases! SMOOCH!
I'll set this in my environment forever!

[Carlos Garcia Campos]

If there's actually a well-known memory threshold for which the AC doesn't work, we could probably disable it automatically.

[Michael Catanzaro]

Well it's going to be based on canvas size, right?

[Dan Jacobson]

All I know is on my other computer with 1 gig, some sites were still failing, but at least less than the number with half a gig. On my third computer with 4 gigs, I never encountered the problem.

As far as canvas size, I was just using a ThinkPad r50e, just your usual laptop. The browser occupied 95% of the screen.

[Carlos Alberto Lopez Perez]

(In reply to Dan Jacobson from comment #10)
> All I know is on my other computer with 1 gig, some sites were still
> failing, but at least less than the number with half a gig. On my third
> computer with 4 gigs, I never encountered the problem.
> 
> As far as canvas size, I was just using a ThinkPad r50e, just your usual
> laptop. The browser occupied 95% of the screen.

Can you try to reproduce this and check if there is any out of memory errors registered on the kernel log ? ( check it with the command: sudo dmesg )

I'm wondering if the site renders white because the kernel killed the webprocess due to an Out-Of-Memory situation (which doesn't happen when AC is disabled), or it renders white because other reason.

[Michael Catanzaro]

(In reply to Carlos Alberto Lopez Perez from comment #11)
> I'm wondering if the site renders white because the kernel killed the
> webprocess due to an Out-Of-Memory situation (which doesn't happen when AC
> is disabled), or it renders white because other reason.

Not likely at all... I guess it would have to be some sort of horrific kill loop to prevent the crash page from ever displaying.

[Dan Jacobson]

(In reply to Carlos Alberto Lopez Perez from comment #11)
OK now reproducing on my low memory machine with
(unset WEBKIT_DISABLE_COMPOSITING_MODE; $BROWSER https://www.webkit.org/&)
yes journalctl -f (dmesg) shows some messages, but only when one finally
closes the browser. Just as it would if I used
WEBKIT_DISABLE_COMPOSITING_MODE=1 and all was normal.