User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:56.0) Gecko/20100101 Firefox/56.0 Build ID: 20170926190823 Steps to reproduce: Open Nightly with a new profile on Linux Mint Debian Edition 64bit ( old profile doesn't work either ) One detail , it appears after ( the same day ) I install and uninstall chromium ( first time for compatibility test , and I still have brave too ) Actual results: No internet page ( it works with nightly 59 ) , no about:home , no about:about ( just the title ) In the terminal : (firefox:25692): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed (firefox:25692): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed (firefox:25692): GLib-GObject-CRITICAL **: g_object_ref: assertion 'object->ref_count > 0' failed ....... ....... (firefox:25692): GLib-GObject-CRITICAL **: g_object_unref: assertion 'object->ref_count > 0' failed No protocol specified Unable to init server: Impossible de se connecter : Connexion refusée (/opt/firefox-nightly2/firefox:25768): Gtk-WARNING **: cannot open display: :0 [Parent 25692, Gecko_IOThread] WARNING: pipe error: Relais brisé (pipe): file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 709 [Parent 25692, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 22 [Parent 25692, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 22 [Parent 25692, Gecko_IOThread] WARNING: pipe error (61): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353 [Parent 25692, Gecko_IOThread] WARNING: pipe error (64): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353 [Parent 25692, Gecko_IOThread] WARNING: pipe error (66): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353 ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0059,name=PContent::Msg_SetPluginList) Channel error: cannot send/recv ...... ..... ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C001F,name=PContent::Msg_PreferenceUpdate) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x15007F,name=PBrowser::Msg_Destroy) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C001F,name=PContent::Msg_PreferenceUpdate) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0001,name=PContent::Msg_PBrowserConstructor) Channel error: cannot send/recv ###!!! [Parent][MessageChannel] Error: (msgtype=0x2C0001,name=PContent::Msg_PBrowserConstructor) Channel error: cannot send/recv No protocol specified Unable to init server: Impossible de se connecter : Connexion refusée (/opt/firefox-nightly2/firefox:25818): Gtk-WARNING **: cannot open display: :0 [Parent 25692, Gecko_IOThread] WARNING: pipe error: Relais brisé (pipe): file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 709 [Parent 25692, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 22 [Parent 25692, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 22 [Parent 25692, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 22 [Parent 25692, Gecko_IOThread] WARNING: FileDescriptorSet destroyed with unconsumed descriptors: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/file_descriptor_set_posix.cc, line 22 [Parent 25692, Gecko_IOThread] WARNING: pipe error (109): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353 [Parent 25692, Gecko_IOThread] WARNING: pipe error (112): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353 [Parent 25692, Gecko_IOThread] WARNING: pipe error (114): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353 [Parent 25692, Gecko_IOThread] WARNING: pipe error (119): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353 [Parent 25692, Gecko_IOThread] WARNING: pipe error (121): Connexion ré-initialisée par le correspondant: file /builds/worker/workspace/build/src/ipc/chromium/src/chrome/common/ipc_channel_posix.cc, line 353 Expected results: Show the page content

Hi sizvix, I tested this issue on Ubuntu 16.04 with FF Nightly 60.0a1(2018-03-09) and I can't reproduce this. Unfortunately, I don't have Linux Mint Debian Edition 64bit to test in the same environment. Please download Firefox Nightly from here: https://nightly.mozilla.org/ and retest the problem.

Hi, Marking this as Resolved: Incomplete due to the lack of response from sizvix. If the issue is still reproducible with the latest Firefox version, feel free to reopen the bug with more information.

I tried this morning ( I have too many things working on nightly to shut down it easily ... but today I had to restart my PC ^^U ) The lastest nightly from https://nightly.mozilla.org/ page ( usely , I tryed with ftp.mozilla.org, I this it's the same ) has the same problem ...

There are other 2 things that can possibly help you. 1. Try in safe mode, if one of your add-ons causes this issue you can find out in this way. Here are the steps: https://support.mozilla.org/t5/Procedures-to-diagnose-and-fix/Troubleshoot-Firefox-issues-using-Safe-Mode/ta-p/1687#w_how-to-start-firefox-in-safe-mode 2. If something is broke with your profile you can find out creating a new one and retest the issue, here are the steps(https://support.mozilla.org/en-US/kb/profile-manager-create-and-remove-firefox-profiles?redirectlocale=en-US&redirectslug=Managing-profiles#w_starting-the-profile-manager) Thanks for your effort.

I tried with new profile. That isn't a problem with Linux Mint Debian Edition 2 , because my laptop has the same distribution and it works. That's a change end of january, the last 59 nightly works.

From your last comment, this issues sounds like and regression. We have a tool called mozregression that we use to find out what fix caused this issue. From here (https://mozilla.github.io/mozregression/) you can install it and find out the regression window. After you install it you can write in your command line this line: mozregression --good 2017-11-13 --bad 2018-03-25 You can also find out more details in the Quick Start section. But I didn't understand if you can reproduce this with the suggestions form comment 4?

At the end of the comparaison , I have this result : ... 2018-03-28T09:45:11: DEBUG : Starting merge handling... 2018-03-28T09:45:11: DEBUG : Using url: https://hg.mozilla.org/integration/autoland/json-pushes?changeset=bd7ff5744eb29e105b7b3c37cb5f46164fa11ef4&full=1 2018-03-28T09:45:12: DEBUG : Found commit message: Bug 1401062 - Avoid doing sandbox-related things to unsandboxed child processes. r=gcp This is a small piece of cleanup that turned out to not be strictly necessary for the rest of this, so I've made it a separate commit. Sandbox-related launch adjustments (currently, interposing libc functions and providing a file descriptor for the syscall reporter) are no longer applied to processes that won't be sandboxed. The MOZ_SANDBOXED environment variable communicates this to the child process, which allows SandboxEarlyInit to be skipped in that case as well. The idea is that disabling sandboxing for a process type, as part of troubleshooting, should disable everything sandbox-related. As a side-effect, this also skips some very minor but unnecessary overhead for NPAPI process startup. MozReview-Commit-ID: D0KxsRIIRN 2018-03-28T09:45:12: INFO : The bisection is done.

Hi Simon GALAIS, Thanks for running mozregression and submitting your results. Form what I see bug 1401062 maybe has something to do with this. Jed can you please take a look at this and see if there is something related to the fix from bug 1401062. Thanks

(In reply to Simon GALAIS from comment #0) > No protocol specified > Unable to init server: Impossible de se connecter : Connexion refusée > > (/opt/firefox-nightly2/firefox:25768): Gtk-WARNING **: cannot open display: :0 The string "No protocol specified" is returned by the X server after failing authorization; the "Unable to init server" is GTK falling back to its Broadway backend and failing. Usually, X11 clients authenticate themselves to the server by reading a shared secret from the $XAUTHORITY file; in principle there are other mechanisms but they all seem to date from when DES was new so they're probably not in current use. Those should all work in this context in any case. There's also a feature, which some distributions use, to authorize local clients based on their uid or gid (obtained with SCM_CREDENTIALS or SO_PEERCRED). So what might be going on here is that the browser is authorized to connect only on the basis of one of its secondary groups (not by uid or shared secret), which doesn't exist in the content process's user namespace. I'll do some testing to see if that might explain it.

(In reply to Jed Davis [:jld] (⏰UTC-6) from comment #9) > So what might be going on here is that the browser is authorized to connect > only on the basis of one of its secondary groups (not by uid or shared > secret), which doesn't exist in the content process's user namespace. I'll > do some testing to see if that might explain it. That's not it — it's using SO_PEERCRED, which returns only the uid and primary gid. (There is support in Xorg for checking supplementary groups, but it depends on a Solaris-specific API.) Also, a process's group memberships are still valid for file permission checks, even if it's in a user namespace where they aren't (and can't be) mapped to local gids, so this probably doesn't have anything to do with that. Backing up a little: the only thing that should have changed for content processes with bug 1401062 is that they're started in new unprivileged user namespaces (but not any other namespace isolation; that was done in followup bugs), with the browser's uid and gid mapped to the same values. None of that should affect X11 authentication in a normal user session… …but if the browser is run as root, the content process won't be allowed to ignore file permissions — it's treated like a regular user whose uid happens to be 0 — so if .Xauthority is owned by a non-root user it won't be readable. We don't support running Firefox as root in a non-root user's session, but we're not currently enforcing that; see bug 1323302.

Are you running Firefox as root? If not: 1. Does "unshare -U xdpyinfo" work, or is it unable to open the display? (If "xdpyinfo" isn't installed, any graphical program should work.) 2. What does "ls -l /opt/firefox-nightly2/firefox" say? (I'm wondering if the firefox executable somehow became setuid root.)

hm ... yes, for many reasons ( better separation for user profile, easyer access to my backend file to develop, ... ) , I use nightly with sudo :-/ So, here "Disallow Firefox from running as sudo" works ^^U ... ( but my laptop still running nightly as sudo ^^ ) ( you should put a popup to say "We disallow Firefox from running as sudo" ^^U )

This is “fixed” by bug 1323302 in that the browser will now refuse to start and print an error message describing why, instead of mysteriously tab-crashing.