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.
Created attachment 314910 [details] midori
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
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.
Possible dup of bug #173768 ("[GTK] Some web pages disappear immediately after rendering")? Does it happen on any websites that don't have videos?
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.
How much memory your system has? Does setting the environment variable WEBKIT_DISABLE_COMPOSITING_MODE=1 before starting the browser helps?
> 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!
If there's actually a well-known memory threshold for which the AC doesn't work, we could probably disable it automatically.
Well it's going to be based on canvas size, right?
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.
(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.
(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.
(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.