Bug 175775
Summary: | REGRESSION(r??????): [GTK] Opening particular web page in epiphany makes everything video inverse in Wayland | ||
---|---|---|---|
Product: | WebKit | Reporter: | Bastien Nocera <bugzilla> |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED INVALID | ||
Severity: | Normal | CC: | aperez, bugs-noreply, clopez, daniel, magomez, mcatanzaro, tpopela, zan |
Priority: | P2 | ||
Version: | Other | ||
Hardware: | Unspecified | ||
OS: | Unspecified | ||
See Also: | https://bugzilla.gnome.org/show_bug.cgi?id=786677 |
Bastien Nocera
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 | ||
---|---|---|
Add attachment proposed patch, testcase, etc. |
Michael Catanzaro
(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
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
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
(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
(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
(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
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
(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
(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
(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
It's certainly a Mutter bug, which I'm working on fixing there. Should be closed as NOTOURBUG.
Bastien Nocera
(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
(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