Description of problem: When running a webkit2gtk process via remote X11 under ssh the webkit process dies with the error: (WebKitWebProcess:2): Gtk-WARNING **: 12:38:30.923: cannot open display: localhost:16.0 (this error was from Epiphany, a similar error occurs when runnin evolution) This error only affects the webkit process, the rest of the program runs normally. Version-Release number of selected component (if applicable): webkit2gtk3-2.30.3-1 also occurs with 2.30.2 How reproducible: always Steps to Reproduce: 1. ssh -Y <remote> or ssh -X <remote> 2. run epiphany or evolution 3. Actual results: webkit process dies with error "cannot open display: localhost:16.0" Expected results: page displays correctly Additional info: openssh-8.4p1-3.fc33.x86_64 epiphany-3.38.1-1.fc33.x86_64 evolution-3.38.1-1.fc33.x86_64 This error started with F33, it did not happen with F32.
Feel free to report this upstream on WebKit Bugzilla. The chances of problems with SSH redirection being addressed here are zero, sorry.
(In reply to Michael Osborne from comment #0) > This error started with F33, it did not happen with F32. ...it did not happen with F32, with the same version of WebKit...?
Correct, the initial version of webkit on F33 was the same as F32. I am not sure that webkit is the true source of the error. It is just the component that is generating the error.
OK, probably not a WebKit bug then.... Unfortunately, I have no clue what component might be responsible.
Could this be https://gitlab.gnome.org/GNOME/mutter/-/merge_requests/1600?
Not this, I'm not using wayland, just plain ole X11.
OK, there's not really anything I can do for you. I haven't used X11 since 2016, and I've never used SSH forwarding ever, and I have not the faintest clue which component to reassign this bug to. And we have established that no change in WebKit is responsible, since the same version of WebKit works fine on F32. So... I can either close this bug, or reassign to another component for triage. I guess ssh, though I have no clue whether there is really any bug in ssh here. I'll get a second opinion....
(In reply to Michael Osborne from comment #0) > Additional info: > openssh-8.4p1-3.fc33.x86_64 > epiphany-3.38.1-1.fc33.x86_64 > evolution-3.38.1-1.fc33.x86_64 > > > This error started with F33, it did not happen with F32. Did you test Epiphany in F32, or only in F33? Guess: Evolution enabled WebKit's sandbox for the first time in F33. If Evolution works in F32, but Epiphany does not, then we can conclude it's related to the sandbox. Try running with WEBKIT_FORCE_SANDBOX=0 and see if that works, please. I asked Ray Strode and he guessed that XAUTHORITY might not be available in the sandbox, but it should be (unless the UI process thinks it is running in Wayland, which it should not), so I don't think that's related. His next guess was the hostname might not be available inside the sandbox, which uses a uts namespace. But I checked the struct utsname returned by uname(), and it does match the host, so it's not that either. CC: Jakub since this is an SSH forwarding issue and we are a bit stumped.
I just checked Epiphany in F32, it gives the same error. I thought I had checked that already. Hmmm, sorry about that. Using WEBKIT_FORCE_SANDBOX=0 both epiphany and evolution work in F33. So, it appears that the sandbox is the culprit.
Hm, interesting. Well that's good news I guess, since modifying the sandbox is pretty easy. I can add a hole for whatever is needed, if only we could figure out what that is. The code is here: https://trac.webkit.org/browser/webkit/trunk/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp?rev=268472 The code that handles Xauthority is here: https://trac.webkit.org/browser/webkit/trunk/Source/WebKit/UIProcess/Launcher/glib/BubblewrapLauncher.cpp?rev=268472#L306
I think we figured it out here: https://gitlab.gnome.org/GNOME/evolution/-/issues/1369#note_1038237. Problem is the web process is trying to connect the X server over a TCP socket, but this is not allowed because it runs in a separate network namespace.
OK, I've created an upstream bug and will post a patch there, which I'm fairly confident will fix this. To actually commit the patch upstream, I need somebody who uses X11 forwarding to test it first, because I don't want to take the time to figure out how to set this up. If you'd be willing to test, I could do a Fedora scratch build to make it easier to try.
Sure thing, I'd be happy to test it.
Thanks, scratch build is here: https://koji.fedoraproject.org/koji/taskinfo?taskID=62169713 At minimum, you'll need webkit2gtk3-2.30.5-2.fc33.x86_64.rpm and webkit2gtk3-jsc-2.30.5-2.fc33.x86_64.rpm.
I tested evolution and epiphany with webkit2gtk3-2.30.5-2.fc33.x86_64.rpm and webkit2gtk3-jsc-2.30.5-2.fc33.x86_64.rpm with multiple users. Everything looks fine now. No visible errors, no relevant errors listed to stdout either. Looks good from here. Thanks!
OK great, thanks for testing.
The latest versions, 2.32.0-1, of webkit2gtk3, and webkit2gtk3-jsc reintroduce this bug. :-( Reopening.
The koji versions, 2.30.5-2, mentioned in comment 14 work fine.
Upstream fix was https://trac.webkit.org/changeset/273965/webkit. That code hasn't changed, so something else must have broken. Are you willing to try bisecting WebKit? It's not going to be fun and could take several days if you don't have an amazing computer, but that's a guaranteed way to figure out what has gone wrong. Otherwise it's hard to guess what could have changed.
Ah nevermind, problem was it was never actually fixed in any release. It's only a regression if you compare to my scratch builds: (In reply to Michael Osborne from comment #18) > The koji versions, 2.30.5-2, mentioned in comment 14 work fine. These worked fine because they were the scratch build with my patch applied. The change is in trunk but never got backported to 2.32. Oops. I will request it for 2.32.1. (Until then, you can downgrade to 2.30.5.)
This should be fixed in 2.32.1.