Bug 168197

Summary: [GTK] Gtk windows should not appear on desktop when running API tests in Wayland
Product: WebKit Reporter: Michael Catanzaro <mcatanzaro>
Component: WebKitGTKAssignee: Nobody <webkit-unassigned>
Status: NEW ---    
Severity: Normal CC: aperez, bugs-noreply, clopez, mcatanzaro
Priority: P2    
Version: WebKit Nightly Build   
Hardware: PC   
OS: Linux   

Description Michael Catanzaro 2017-02-12 11:52:57 PST
When running /webkit2/WebKitPrintOperation/custom-widget, a GtkWindow appears on my screen and I get to watch as the print dialog is opened and closed. This happens when running several other API tests too. It shouldn't.

This is probably a Wayland-specific problem as I don't think I've ever seen this when using X.
Comment 1 Carlos Alberto Lopez Perez 2017-02-12 15:03:45 PST
(In reply to comment #0)
> When running /webkit2/WebKitPrintOperation/custom-widget, a GtkWindow
> appears on my screen and I get to watch as the print dialog is opened and
> closed. This happens when running several other API tests too. It shouldn't.
> 
> This is probably a Wayland-specific problem as I don't think I've ever seen
> this when using X.

Are you passing --display-server=wayland to Tools/Scripts/run-gtk-tests ? Then that is the expected behaviour (you see the window)

To avoid that, you should pass --display-server=weston to the run-gtk-tests script. That would execute the test inside a virtualized Weston server (on top of xvfb)
Comment 2 Michael Catanzaro 2017-02-12 15:56:33 PST
(In reply to comment #1)
> (In reply to comment #0)
> > When running /webkit2/WebKitPrintOperation/custom-widget, a GtkWindow
> > appears on my screen and I get to watch as the print dialog is opened and
> > closed. This happens when running several other API tests too. It shouldn't.
> > 
> > This is probably a Wayland-specific problem as I don't think I've ever seen
> > this when using X.
> 
> Are you passing --display-server=wayland to Tools/Scripts/run-gtk-tests ?
> Then that is the expected behaviour (you see the window)

No, I'm just running the tests manually (because run-gtk-tests doesn't support running individual tests and expects to use a build directory created by build-webkit, which I avoid except when required to run layout tests as that's incompatible with use by Epiphany), which works fine under X11. If we can make this work in X11 without the script, it should be possible to do it in Wayland too, right?

> To avoid that, you should pass --display-server=weston to the run-gtk-tests
> script. That would execute the test inside a virtualized Weston server (on
> top of xvfb)

I would also expect the script to work properly by default, without passing any additional arguments. But I think it's fine if that uses xvfb without weston, which to my understanding is the current behavior.
Comment 3 Michael Catanzaro 2017-02-12 15:57:48 PST
(In reply to comment #2)
> No, I'm just running the tests manually (because run-gtk-tests doesn't
> support running individual tests and expects to use a build directory
> created by build-webkit, which I avoid except when required to run layout
> tests as that's incompatible with use by Epiphany), which works fine under
> X11.

(It's possible that I'm crazy and misremembering that this used to work in X11... but I think it did.)
Comment 4 Michael Catanzaro 2017-02-12 16:04:17 PST
Ah I'm dumb, it probably has a lot to do with this error I see when running every test, which I should have mentioned in the first post:

$ echo $XDG_RUNTIME_DIR
/run/user/1000
$ jhbuild run ./TestWebViewEditor -p /webkit2/WebKitWebView/select-all/non-editable
/webkit2/WebKitWebView/select-all/non-editable: error: XDG_RUNTIME_DIR not set in the environment
Nested Wayland compositor could not create display socket

I have no clue where XDG_RUNTIME_DIR is getting unset.
Comment 5 Carlos Alberto Lopez Perez 2017-02-13 03:39:02 PST
(In reply to comment #2)
> (In reply to comment #1)
> > (In reply to comment #0)
> > > When running /webkit2/WebKitPrintOperation/custom-widget, a GtkWindow
> > > appears on my screen and I get to watch as the print dialog is opened and
> > > closed. This happens when running several other API tests too. It shouldn't.
> > > 
> > > This is probably a Wayland-specific problem as I don't think I've ever seen
> > > this when using X.
> > 
> > Are you passing --display-server=wayland to Tools/Scripts/run-gtk-tests ?
> > Then that is the expected behaviour (you see the window)
> 
> No, I'm just running the tests manually (because run-gtk-tests doesn't
> support running individual tests and expects to use a build directory
> created by build-webkit, which I avoid except when required to run layout
> tests as that's incompatible with use by Epiphany),

I think you are doing it wrong. The tests are not meant to be executed directly.

If there is some use case that prevents you to use the run-gtk-tests script, then we should improve the script rather than trying to find a way around it.

> which works fine under
> X11. If we can make this work in X11 without the script, it should be
> possible to do it in Wayland too, right?
> 

No, with X11 happens the same if you run the test manually.. you see windows appearing on the screen.

> > To avoid that, you should pass --display-server=weston to the run-gtk-tests
> > script. That would execute the test inside a virtualized Weston server (on
> > top of xvfb)
> 
> I would also expect the script to work properly by default, without passing
> any additional arguments. But I think it's fine if that uses xvfb without
> weston, which to my understanding is the current behavior.

The script defaults to use xvfb. So you should not see any window appearing in your screen if you use the script.
Comment 6 Adrian Perez 2018-05-03 04:17:38 PDT
As far as I can understand, it's normal that windows appear when
manually running tests (it has always been like that for me, BTW),
and of course one is expected to use “run-webkit-tests”... which
means there is no bug. Michael, do you think we can close this bug?
If the XDG_RUNTIME_DIR issue still applies, maybe we can reword the
title/description or just open a new one.
Comment 7 Michael Catanzaro 2018-05-03 08:57:10 PDT
It's not normal, we used to display the windows offscreen.