User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Build ID: 20170520072017 Steps to reproduce: * Force enable multiprocess by setting browser.tab.remote.force-enable to true in about:config * Run firefox in safe mode (with all of the plugins disabled) * Go to https://facebook.com and log in Actual results: Shortly after loading the page facebook's chat gets disconnected. In order to receive messages one must refresh the page. Expected results: Facebook's chat should remain connected (the case when multiprocess is disabled)
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Firefox/53.0 Hi and thanks for the report. I tried to reproduce the issue you described, but the Facebook chat didn't disconnect and there were no problems in sending/receiving messages. I used Ubuntu 14.04 x32 and 16.04 x64 and Firefox version 53.0.3 (Build ID: 20170518070317) and followed the next steps to reproduce: 1. After forcing enabling multiprocess by creating a new Boolean with the pref you mentioned in comment 0, I started Firefox in Safe Mode and logged in the Facebook account. The chat didn't disconnect and sending/receiving messages worked as expected. 2. I didn't create the pref you mentioned since e10s was already enabled by default. I just started Firefox in Safe Mode, logged in the Facebook account and the results were the expected ones, no issues related to chat nor sending/receiving messages. I must mention that after logging into the Facebook account, I even waited for about 10 minutes with Firefox in background, meanwhile sending messages to that Facebook account. After focusing Firefox again, the message chat tab was opened displaying the messages. Also, the new messages red notification was displayed on Facebook's toolbar and the chat was still connected. Can you please try to reproduce this issue on the latest Nightly build? You can download it from here: https://nightly.mozilla.org/ Thank you!
Sorry for the delay on the info. I can reproduce this bug with the latest nightly (56.0a1 (2017-06-13)) in the safe mode. I'm on Arch linux with kernel 4.10.13-1-ARCH x86_64. The disconnect happens almost immediately - roughly 2-3 seconds after the page is loaded. What might be an important additional information here is that I run firefox via the firejail application (version 0.9.46) with the default profile for firefox.
I just checked it without firejail and I can still reproduce that issue in the latest nightly, so it looks like firejail is not a factor in this problem.
I tried again to reproduce the issue on Ubuntu 16.06 x64 but without success. Can you please try the following scenarios and report back the results? Scenario A: 1. Create a new profile . 2. Make sure e10s is disabled. 3. Navigate to Facebook normally (without Safe Mode). Does Facebook's chat still disconnect? Can you receive/send any messages? Scenario B: 1. Make sure e10s is enabled. 2. Navigate to Facebook normally (without Safe Mode). Does Facebook's chat still disconnect? Can you receive/send any messages? Also, as you're able to reproduce the issue on your machine, you can narrow down a regression range with Mozregression tool. Please see  for details. After the run, paste here the final pushlog from repo mozilla-inbound. Thank you!  https://support.mozilla.org/en-US/kb/troubleshoot-and-diagnose-firefox-problems?cache=no#w_6-create-a-new-firefox-profile  http://mozilla.github.io/mozregression/
To my surprise, in Scenario A Facebook's chat seems to be working perfectly fine, whereas the issue persists in Scenario B. That looks like a problem with my profile. I should mention that I have upgraded to Firefox version 54. As for the regression range - I am not sure how can I find the first good commit, as Facebook's chat have never worked for me with e10s enabled. Do you want me to try to find a possibly good commit with my current profile, or should I just port to a new one and forget about this issue? The source of this issue might be quite problematic to track down, as my profile directory have been moved around between different linux distributions throughout the last few years. Thank you for your help, I greatly appreciate it!
I was able to narrow down the problem to the possibly corrupt permissions.sqlite file. After changing its name in my old profile firefox generates a fresh new permissions.sqlite and with e10s enabled I can no longer reproduce the bug. If anyone wants to investigate this problem further I'm willing to help, as I have the oldfaulty permissions.sqlite file saved.
Based on Comment 6 from the reporter, changing status to RESOLVED WORKS FOR ME. If anyone can still reproduce it on latest versions, feel free to reopen the issue and provide more information.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 10 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.