1319055 - E10s is automatically turned on and prevents FF from loading websites

Status: RESOLVED INCOMPLETE

(Core :: IPC, defect, P3)

Description

[bugs]

User Agent: Mozilla/5.0 (Windows NT 6.1; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/41.0.2272.118 Safari/537.36
Build ID: 20161019084923

Steps to reproduce:

1) Firefox updated automatically to version 50.
2) No website could be loaded, not even a local HTML-file from disk.
3) I created a new profile and deleted the old profile
4) Everything seemed to work fine now.
5) I restarted Firefox.
6) Again, no website could be loaded (start over at 3 to solve the issue temporarily)
7) Switching browser.tabs.remote.autostart2 to false seems to solve the issue.


Actual results:

After updating Firefox to version 50, I tried to surf https://www.google.com. I just got a blank, white screen not even showing, that firefox was trying to load the page.


Expected results:

The website https://www.google.com should have been loaded and displayed.

Comment 1

[bugs]

Attachment: Log of the HTTP activity, when the bug appears

Comment 2

[[:philipp]]

tentatively moving this to core:networking as well...

Comment 3

[Dragana Damjanovic [:dragana]]

I was talking with philipp on irc, I will take a look at this.

Comment 4

[Honza Bambas (:mayhemer)]

Reporter, I can see a lot of activity in the log you provided.  Can you say what URLs where you navigating to?  We need to look for something in the log.  It's hard w/o more info about what you were doing when that log was captured.

Thanks.


Honestly, I don't think this is a network bug from the first look, but more info still needed.

Comment 5

[Honza Bambas (:mayhemer)]

Also, can you please paste content of 'about:support' page here?  It may tells us about any globally installed addons that can break in e10s.  Thanks.

Comment 6

[Dragana Damjanovic [:dragana]]

This looks very much as non-networking bug. There is not request for necko at all.

Comment 7

[bugs]

Honza Bambas when I captured the log, I just went to http://www.heise.de

I'll profide the content of 'about:support' tomorrow morning. Do I have to turn on e10s again before pasting the contents of 'about:support:?
Thanks for fixing my typo.

Comment 8

[Honza Bambas (:mayhemer)]

(In reply to bugs from comment #7)
> Honza Bambas when I captured the log, I just went to http://www.heise.de

Since you only provided the chrome (parent) process log (and no .child-N log) we don't know if this has stopped before the request bubbled to the network parts on the child (content) process.

Anyway, there is no request to http://www.heise.de in the parent process log.

> 
> I'll profide the content of 'about:support' tomorrow morning. Do I have to
> turn on e10s again before pasting the contents of 'about:support:?
> Thanks for fixing my typo.

No, you don't have to switch to e10s.  The content of about:support will be the same.

Thanks!

Comment 9

[bugs]

(In reply to Honza Bambas (:mayhemer) from comment #8)
> (In reply to bugs from comment #7)
> > Honza Bambas when I captured the log, I just went to http://www.heise.de
> 
> Since you only provided the chrome (parent) process log (and no .child-N
> log) we don't know if this has stopped before the request bubbled to the
> network parts on the child (content) process.

I captured it, like shown at https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging "Logging HTTP activity using evironment variables". What else do you need?

Sorry for needing more time for providing about:support.

Comment 10

[bugs]

Attachment: about_support.txt

Comment 11

[Honza Bambas (:mayhemer)]

(In reply to bugs from comment #9)
> (In reply to Honza Bambas (:mayhemer) from comment #8)
> > (In reply to bugs from comment #7)
> > > Honza Bambas when I captured the log, I just went to http://www.heise.de
> > 
> > Since you only provided the chrome (parent) process log (and no .child-N
> > log) we don't know if this has stopped before the request bubbled to the
> > network parts on the child (content) process.
> 
> I captured it, like shown at
> https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging
> "Logging HTTP activity using evironment variables". What else do you need?

OK, if you do it according those directions then there should be two or more log files.  log.txt and also log.txt-child1, log.txt-child2 etc.  Some are coming from the content (child) process we render pages at.  Some are produced by plugins such as Flash.  If there were only one but the e10s (aka multi-process) is turned on, then the problem might be that we failed to start the content process from some reason (maybe A/V software interference?)

If they are there, all of them are important for finding out cause of this bug.

> 
> Sorry for needing more time for providing about:support.

No problem.

I don't see any externally installed add-ons there, so it seems like issues you have are coming from Firefox itself or the system.


So, the next step would be to create one more clean profile (side by your current profile, no need to destroy it), setup logging environment vars and run firefox with that new profile.

There is a simpler way to switch to a different profile: 
- create an empty writable directory whenever it suits you
- make sure that no other instance of Firefox is running
- then open cmd.exe (the Command Prompt, just search for "cmd" in the Start menu) 
- set logging environment vars in the prompt (if you did not globally, which is IMO not recommended)
- then run in prompt:

"C:\Program Files (x86)\firefox.exe" -profile "c:\path-to-profile-dir" -no-remote

Try to reproduce.  After the bug is reproduced, close firefox and look for the log files.  Submit them all here or send by mail to me.

Thank you.

Comment 12

[[:philipp]]

in the meantime we received similar reports on sumo by other users from a corporate environment who said that multiple workstations were affected, so it seems likely that the issue is coming from a particular system configuration or third-party influence.

"This troubling behavior started popping up across dozens of workstations in our organization."
https://support.mozilla.org/questions/1147827

"I have several users at my company that have this same behavior"
https://support.mozilla.org/questions/1147674

Comment 13

[Dragana Damjanovic [:dragana]]

Any news here?

Comment 14

[Honza Bambas (:mayhemer)]

I believe this is duplicate of bug 1320360.  But the log submitted here (on 2016-11-21) is pretty useless, so hard to say for sure.

Comment 15

[[:philipp]]

we still get occasional user reports about this - the last one was from a mac: https://support.mozilla.org/questions/1155656

Comment 16

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 17

[Firefox Bug Husbandry Bot]

Bulk change to priority: https://bugzilla.mozilla.org/show_bug.cgi?id=1399258

Comment 18

[mhamzakhan]

I currently have the bug on my installation for the last 2 days. The version is Firefox 58.0a1 Build ID 20171012105833.
The issue seems to get resolved by setting "browser.tabs.remote.autostart.2" to "false".

I collected the logs using "Logging HTTP activity by manually setting environment variables" from https://developer.mozilla.org/en-US/docs/Mozilla/Debugging/HTTP_logging

The logs are attached as "Nightly-Bug.zip". Note that the "log.txt.child-1.0" file had 0 bytes.
I tried to browse to "www.google.com", "about:about" and "about:config". None of them worked.

A few observations:

1) Links typed in the address bar do not seems to work mostly.
2) I was only able to open the "about:config" page by going to "about:addons" and then moving to "about:config". Second time I had "about:config" tab open and reloading it worked.
3) When you open firefox, two windows open. One is the main window where you can open tabs. The second is a window that you cannot maximize and you cannot see even if you close everything else. Only the taskbar in windows shows two tabs open. The second window persists for a while even after you close the main one.

Let me know if you need anything more. I will not upgrade nightly for a few days in case more logs are required.

Comment 19

[mhamzakhan]

Attachment: Logs for the bug on Nightly 58.0a1

Comment 20

[Honza Bambas (:mayhemer)]

This looks like initiation of the child process or the IPC fails.  The HTTP log shows there are no HttpChannelParent objects created.  There are only searches performed on the parent processes via the search bar for "google", "about" and "www" strings + few service parent process initiated requests (all expected).

Comment 21

[mhamzakhan]

Another comment from my side, might be unrelated.

A few days before this issue started, the browser had been acting funny already. Redirects with SSO logins were not working. It used to get stuck on the SSO login page.

Since I set the "browser.tabs.remote.autostart.2" to false, that issue seems to have disappeared too.

Comment 22

[Andrew McCreight [:mccr8]]

I don't think we're going to be able to do anything about a bug this old going on logs alone. Hopefully the issue has been fixed in the mean time.