For doing some openQA tests which require a web browser but no other part of a graphical desktop, we do this, starting from a minimal or Server install: dnf groupinstall base-x dnf install firefox startx /usr/bin/firefox https://www.google.com (or some other URL, obviously). Recently on Rawhide - I think since Firefox 52.0.2 arrived - this has been failing. Firefox runs, but immediately shows the 'Gah. Your tab just crashed.' error message. Trying to load any URL by typing it in the URL bar shows the same error. Clicking 'Restore this tab' just shows a blank grey pane and the URL in the URL bar; hitting enter in the URL bar shows the error message again. Firefox seems to work fine when running as part of GNOME, though (the KDE test hasn't run yet today). So this is somehow specific to running direct on top of X, or a missing dependency, or something. I'm not sure how to get more useful info to debug it further; nothing useful seems to be shown at the console after I close Firefox (and thus the X session). I know this is a slightly odd way to run Firefox, but it's rather important to our Cockpit and FreeIPA tests, so ranking it as 'high' severity.
Ah, if I install icewm and run Firefox from an xterm within icewm, it behaves the same, and I see these errors on the console: No protocol specified Unable to init server: Could not connect: Connection refused (/usr/lib64/firefox/plugin-container:3007): Gtk-WARNING **: cannot open display: :0 [Parent 2957] WARNING: pipe error (42): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 [Parent 2957] WARNING: pipe error (46): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 [Parent 2957] WARNING: pipe error (45): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 [Parent 2957] WARNING: pipe error (44): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 [Parent 2957] WARNING: pipe error (48): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0082,name=PBrowser::Msg_LoadRemoteScript) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0082,name=PBrowser::Msg_LoadRemoteScript) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0082,name=PBrowser::Msg_LoadRemoteScript) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0082,name=PBrowser::Msg_LoadRemoteScript) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0082,name=PBrowser::Msg_LoadRemoteScript) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C006A,name=PBrowser::Msg_UpdateDimensions) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0085,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv No protocol specified Unable to init server: Could not connect: Connection refused (/usr/lib64/firefox/plugin-container:3021): Gtk-WARNING **: cannot open display: :0 [Parent 2957] WARNING: pipe error (48): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 [Parent 2957] WARNING: pipe error (52): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 [Parent 2957] WARNING: pipe error (51): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 [Parent 2957] WARNING: pipe error (53): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 [Parent 2957] WARNING: pipe error (55): Connection reset by peer: file /builddir/build/BUILD/firefox-52.0.2/firefox-52.0.2/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 322 ###!!! [Parent][MessageChannel] Error: (msgtype=0x46001C,name=PContent::Msg_PreferenceUpdate) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x460044,name=PContent::Msg_LoadProcessScript) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x460044,name=PContent::Msg_LoadProcessScript) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x46010A,name=PContent::Msg_AsyncMessage) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x46010A,name=PContent::Msg_AsyncMessage) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0085,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv
Hmm. So if I run 'xhost +' before running Firefox within icewm, it works. So there's some X ACL stuff going on here, I guess. Not sure why root can't connect to its own X session by default, but there is an error "File /root/.serverauth.NNNN does not exist" shown on the console, though an ls while the X session is running shows that file *is* there. Odd. Still, doesn't seem to be a Firefox issue, exactly.
Changing this line: enable_xauth=1 to this: enable_xauth=0 in /usr/bin/startx 'solves' this problem, so it's definitely something to do with X ACLs.
Hi Adam, My advise would be to create a test user (useradd test) and run the tests as that user. Running GUI apps as root is really not tested / supported and things breaking there are not unexpected, some apps even detect that they are running as root and simply exit with an error. As for this specific bug, can you try starting a xterm ? Ig you can start a xterm the xauth setup is fine and the problem is firefox getting confused from running as root. Regards, Hans
"My advise would be to create a test user (useradd test) and run the tests as that user." I really don't want to do that, as it adds more complication to the tests, and that means they're inevitably more likely to break down. "and the problem is firefox getting confused from running as root." I don't think it is, because - as I explained - Firefox works fine if I run 'xhost +' before running it, or change the 'enable_xauth' line in startx.
(In reply to Adam Williamson from comment #5) > "My advise would be to create a test user (useradd test) and run the tests > as that user." > > I really don't want to do that, as it adds more complication to the tests, > and that means they're inevitably more likely to break down. Not a single bit in the whole gui stack is designed to run as root / ever tested running as root, so you're avoiding some complexity in your test scripts (and TBH really not that much complexity) and at the same time going down a deep rabit hole, one where many developers will tell you when you file bug reports: "Do not run gui apps as root, bug closed" > "and the problem is firefox getting confused from running as root." > > I don't think it is, because - as I explained - Firefox works fine if I run > 'xhost +' before running it, or change the 'enable_xauth' line in startx. Is this is a normal login session btw or are you doing startx over ssh ? IMHO you should really try to mimick a normal environment as much as possible in the tests, otherwise you are bound to both hit issues no one is seeing in normal environments *and* miss issues people are actually seeing. Lets for example say there is some file-permission issue, how are your tests going to catch those if you run them as root ? Note I just tried startx icewm-session and then xterm -> firefox as root and that works on F25. Re-reading your earlier comments I see that you can start both icewm and a xterm in icewm that pretty much excludes any xauth problems, xauth is pretty binary, either it works or it does not work.
That may be also caused by e10s - try to set browser.tabs.remote.autostart to false in about:config.
I didn't 'startx icewm-session', I did 'startx /usr/bin/icewm'. "Lets for example say there is some file-permission issue, how are your tests going to catch those if you run them as root ?" These aren't tests of Firefox, or anything like that. They're testing Cockpit and the FreeIPA web UI. "Is this is a normal login session btw or are you doing startx over ssh ?" Normal login session. "that pretty much excludes any xauth problems, xauth is pretty binary, either it works or it does not work." Sorry, but you seem to keep ignoring the very obvious thing I keep saying: *it works when I turn xauth off*. So long as that's the case, and you don't actually respond to that assertion, it's difficult for me to believe that xauth is not in fact the problem.
(In reply to Adam Williamson from comment #8) > Sorry, but you seem to keep ignoring the very obvious thing I keep saying: > *it works when I turn xauth off*. So long as that's the case, and you don't > actually respond to that assertion, it's difficult for me to believe that > xauth is not in fact the problem. If xterm / other apps can connect to the xserver then you've a XAUTHORITY environment variable pointing to a valid xauth file, otherwise no apps would be able to connect. That firefox does not work could for example mean that it is not looking at XAUTHORITY when running as root (maybe the wrapper script firefox uses cleans the environment?) or one of many other things, but it is unlikely that if only firefox is having trouble connecting that this is a problem in startx / xinit.
well, there is that error about the file 'not existing' which shows up on the terminal (even though the file does exist). But at this point I've got a workaround (I just have the test run a sed on startx before running firefox), so let's just close this.
FWIW, the ""File /root/.serverauth.NNNN does not exist" message is not an error, it simply is xauth (the cmdline util invoked by startx) letting you know it is creating a new file rather then appending credentials to an existing file.