From https://bugzilla.gnome.org/show_bug.cgi?id=748829 Original bug report (slightly altered): When trying to load DuckDuckGo pages in Epiphany under Wayland, you either get a blank page if you've entered the address in the address name, or if you clicked on an entry in the new tab page you just get a different window name and address, the page stays the same. webkit2gtk 2.8.1-1, Web (Epiphany) 3.16, GNOME 3.16.1, Arch Linux (fully updated). Thanks.
Thanks for taking the time to move this bug report. So we have a series of bugs that only occur on a few web sites, including duckduckgo.com: [list][*]Scrolling is extremely slow on particular pages, including DuckDuckGo: https://bugs.freedesktop.org/show_bug.cgi?id=85064 [*]Hidpi does not work on particular pages, including DuckDuckGo: https://bugs.webkit.org/show_bug.cgi?id=141782 [*]This bug [/list] It would be an impressive coincidence if these bugs were unrelated. I don't think DDG is that unlucky. I'm planning to try to disabling all OpenGL-related options in the Fedora build to see if these bugs go away when they're disabled. (This requires a small bit of effort to fix the build with these options disabled, which is why I haven't done so yet.)
Not sure why I thought BBCode would work on Bugzilla. :D
Don't forget that it works fine on X. Only Wayland is affected.
I guess accelerated compositing is to blame. We'll have to either fix it or disable it prior to Fedora 23 when we switch to Wayland by default.
(In reply to comment #4) > I guess accelerated compositing is to blame. We'll have to either fix it or > disable it prior to Fedora 23 when we switch to Wayland by default. Disabling accelerated compositing would break 3D CSS transforms and make WebGL pretty unusable, so hopefully we can fix this.
OK, many (not all!) pages on GitHub are broken in Wayland too. In X, GitHub is affected by fdo#85064, just like DuckDuckGo. Most other sites are unaffected. I would bet more than I should that hipdi is broken on GitHub as well. So I'm pretty sure all three issues are related. We've independently guessed accelerated compositing is to blame for fdo#85064 and the hidpi bug, so it seems like a good guess here too. Is accelerated compositing is something that's only used sometimes, based on some heuristic? Do any important sites break without 3D CSS transforms? We already disable WebGL in Epiphany, so that won't be a regression for us. I'm pretty sure these three bugs are much more serious. I always prefer a proper fix to a workaround and hate to disable all your work on accelerated compositing, but if that fixes these issues we should absolutely do so.
(In reply to comment #6) > Do any important sites break without 3D CSS transforms? We already disable > WebGL in Epiphany, so that won't be a regression for us. I'm pretty sure > these three bugs are much more serious. I always prefer a proper fix to a > workaround and hate to disable all your work on accelerated compositing, but > if that fixes these issues we should absolutely do so. I think a better approach is to simply fix this bug than to disable anything. I don't think AC or hidpi are features that we can reasonably turn off.
(In reply to comment #7) > (In reply to comment #6) > > > Do any important sites break without 3D CSS transforms? We already disable > > WebGL in Epiphany, so that won't be a regression for us. I'm pretty sure > > these three bugs are much more serious. I always prefer a proper fix to a > > workaround and hate to disable all your work on accelerated compositing, but > > if that fixes these issues we should absolutely do so. > > I think a better approach is to simply fix this bug than to disable > anything. I don't think AC or hidpi are features that we can reasonably turn > off. To expand on this, if hidpi support was added without considering accelerated compositing mode, the feature is incomplete and needs to be finished.
It seems I can reproduce this bug reliably using WebKitGTK+ 2.8.1 packaged for Fedora 22, but not using my development build. Perhaps the problem only exists in the 2.8 branch. (In reply to comment #8) > To expand on this, if hidpi support was added without considering > accelerated compositing mode, the feature is incomplete and needs to be > finished. That seems to be the case. :(
*** This bug has been marked as a duplicate of bug 115803 ***
I marked this as a dup of bug #115803 but it's not really. We don't need to support accelerated compositing, we just need to not try to use it and fail. That's working now when built with ENABLE_WAYLAND_TARGET=ON, so when 2.10 is released, convince your distro to build with ENABLE_WAYLAND_TARGET=ON. I'm going to try enabling it in Fedora rawhide now.