RESOLVED INVALID Bug 175775
REGRESSION(r??????): [GTK] Opening particular web page in epiphany makes everything video inverse in Wayland
https://bugs.webkit.org/show_bug.cgi?id=175775
Summary REGRESSION(r??????): [GTK] Opening particular web page in epiphany makes ever...
Bastien Nocera
Reported 2017-08-21 09:55:28 PDT
webkitgtk4-2.17.91-1.fc28.x86_64 Launching the MiniBrowser with this page makes all the WebKit-based apps video-inverted. 1. Launch: /usr/libexec/webkit2gtk-4.0/MiniBrowser https://copr.fedorainfracloud.org/coprs/pjones/efi32cpu64/packages/ 2. The whole MiniBrowser window is video inverted, blue borders are brown, so is that page's background, the icons in the toolbars. Same thing happens in epiphany.
Attachments
Michael Catanzaro
Comment 1 2017-08-21 15:31:31 PDT
(In reply to Bastien Nocera from comment #0) > webkitgtk4-2.17.91-1.fc28.x86_64 Can't reproduce with webkitgtk4-2.16.6-1.fc27.x86_64. Looks like we have a pretty severe regression. We have three weeks to fix it or bisect and revert.
Adrian Perez
Comment 2 2017-08-21 16:36:00 PDT
I tried the following WebKitGTK+ versions, cannot reproduce the issue with any of them: - WebKitGTK+ 2.16.6, Epiphany 3.24.3 (Arch Linux packages) - WebKitGTK+ 2.17.91, Epiphany 3.25.90 (built by me) - WebKitGTK+ and MiniBrowser from trunk, r220984 (built by me) I wonder if the reported issue may have something to do with the build options being used for the Fedora package. In the past there has been issues with “RelWithDebInfo” builds. From the build logs at https://kojipkgs.fedoraproject.org//packages/webkitgtk4/2.17.91/1.fc28/data/logs/x86_64/build.log it is clear that a “Release” build is being made, so I wonder if this may have something to do with the other build options (CFLAGS/CXXFLAGS/etc).
Tomas Popela
Comment 3 2017-08-23 03:18:03 PDT
My tests: my F26 (T450s, Intel® HD Graphics 5500 (Broadwell GT2), mesa-libGL-17.1.5-1.fc26.x86_64) + trunk WebKitGTK+ and trunk Epiphany - no problem F27 (XPS 13, Intel® HD Graphics 620 (Kaby Lake GT2), mesa-libGL-17.2.0-0.1.rc4.fc27.x86_64) + 2.17.90 + MiniBrowser - no problem F27 (XPS 13, Intel® HD Graphics 620 (Kaby Lake GT2), mesa-libGL-17.2.0-0.1.rc4.fc27.x86_64) + 2.17.91 + MiniBrowser - no problem > I wonder if the reported issue may have something to do with the build > options being used for the Fedora package. In the past there has been > issues with “RelWithDebInfo” builds. You are mixing things Adrian :), these problems with RelWithDebInfo were my local build problems, we never used anything different than Release in Fedora packages.
Bastien Nocera
Comment 4 2017-08-23 03:21:54 PDT
(In reply to Tomas Popela from comment #3) > My tests: > > my F26 (T450s, Intel® HD Graphics 5500 (Broadwell GT2), > mesa-libGL-17.1.5-1.fc26.x86_64) + trunk WebKitGTK+ and trunk Epiphany - no > problem > F27 (XPS 13, Intel® HD Graphics 620 (Kaby Lake GT2), > mesa-libGL-17.2.0-0.1.rc4.fc27.x86_64) + 2.17.90 + MiniBrowser - no problem > F27 (XPS 13, Intel® HD Graphics 620 (Kaby Lake GT2), > mesa-libGL-17.2.0-0.1.rc4.fc27.x86_64) + 2.17.91 + MiniBrowser - no problem Kaby Lake? Posh boy ;) Mine's an "Haswell Desktop" GPU. Same version of Mesa, and the machine was updated as of yesterday. Note that I also use Wayland under gnome-shell. Do you manage to reproduce with that?
Tomas Popela
Comment 5 2017-08-23 03:36:22 PDT
(In reply to Bastien Nocera from comment #4) > (In reply to Tomas Popela from comment #3) > > My tests: > > > > my F26 (T450s, Intel® HD Graphics 5500 (Broadwell GT2), > > mesa-libGL-17.1.5-1.fc26.x86_64) + trunk WebKitGTK+ and trunk Epiphany - no > > problem > > F27 (XPS 13, Intel® HD Graphics 620 (Kaby Lake GT2), > > mesa-libGL-17.2.0-0.1.rc4.fc27.x86_64) + 2.17.90 + MiniBrowser - no problem > > F27 (XPS 13, Intel® HD Graphics 620 (Kaby Lake GT2), > > mesa-libGL-17.2.0-0.1.rc4.fc27.x86_64) + 2.17.91 + MiniBrowser - no problem > > Kaby Lake? Posh boy ;) That's not mine :/ :D > Mine's an "Haswell Desktop" GPU. > > Same version of Mesa, and the machine was updated as of yesterday. Note that > I also use Wayland under gnome-shell. Do you manage to reproduce with that? OK, the XPS ones were on X11. If we switch to Wayland then we can reproduce it with webkitgtk4 2.17.91 and even with 2.17.90. What I see is also that initially it is blue as it's supposed to be, but then it nearly immediately inverts.
Bastien Nocera
Comment 6 2017-08-23 03:41:07 PDT
(In reply to Tomas Popela from comment #5) > OK, the XPS ones were on X11. If we switch to Wayland then we can reproduce > it with webkitgtk4 2.17.91 and even with 2.17.90. What I see is also that > initially it is blue as it's supposed to be, but then it nearly immediately > inverts. \o/ success in failure!
Tomas Popela
Comment 7 2017-08-23 04:18:47 PDT
OK, I thought that I can start bisecting it in F27 VM, but no luck as: [tpopela@localhost ~]$ /usr/libexec/webkit2gtk-4.0/MiniBrowser https://copr.fedoraproject.org WaylandCompositor requires eglCreateImage and eglDestroyImage. Nested Wayland compositor could not initialize EGL Hopefully someone will be willing to update to F27 (or is already on F27) and bisect it (if not, I will update to F27 myself)..
Michael Catanzaro
Comment 8 2017-08-23 07:53:13 PDT
(In reply to Tomas Popela from comment #3) > You are mixing things Adrian :), these problems with RelWithDebInfo were my > local build problems, we never used anything different than Release in > Fedora packages. I did an audit of the build system a few weeks ago and it should be safe to switch to RelWithDebInfo now, which is the right build type for Linux distributions anyway. I think that should already be selected by the %cmake macro.
Carlos Alberto Lopez Perez
Comment 9 2017-08-23 09:08:49 PDT
(In reply to Michael Catanzaro from comment #8) > (In reply to Tomas Popela from comment #3) > > You are mixing things Adrian :), these problems with RelWithDebInfo were my > > local build problems, we never used anything different than Release in > > Fedora packages. > > I did an audit of the build system a few weeks ago and it should be safe to > switch to RelWithDebInfo now, which is the right build type for Linux > distributions anyway. I think that should already be selected by the %cmake > macro. When building natively on a 32-bit system or when the build host has less than XGB of RAM available there can be problems with the linking steps and not enough RAM. In that case passing -g1 instead of -g helps. Check bug 100670 (from the autotools age, but the core of the issue is still a thing AFAIK)
Bastien Nocera
Comment 10 2017-08-23 11:54:05 PDT
(In reply to Bastien Nocera from comment #6) > (In reply to Tomas Popela from comment #5) > > OK, the XPS ones were on X11. If we switch to Wayland then we can reproduce > > it with webkitgtk4 2.17.91 and even with 2.17.90. What I see is also that > > initially it is blue as it's supposed to be, but then it nearly immediately > > inverts. > > \o/ > > success in failure! It might be a problem with GL, or gnome-shell though. Totem and Cheese show the same video inverse problem.
Daniel Stone
Comment 11 2017-08-24 02:04:00 PDT
It's certainly a Mutter bug, which I'm working on fixing there. Should be closed as NOTOURBUG.
Bastien Nocera
Comment 12 2017-08-24 02:46:02 PDT
(In reply to Daniel Stone from comment #11) > It's certainly a Mutter bug, which I'm working on fixing there. Should be > closed as NOTOURBUG. Do you have an upstream bug reference for it?
Daniel Stone
Comment 13 2017-08-24 02:50:12 PDT
(In reply to Bastien Nocera from comment #12) > (In reply to Daniel Stone from comment #11) > > It's certainly a Mutter bug, which I'm working on fixing there. Should be > > closed as NOTOURBUG. > > Do you have an upstream bug reference for it? https://bugzilla.gnome.org/show_bug.cgi?id=786677
Note You need to log in before you can comment on or make changes to this bug.