Dialog "Plugin Container for Firefox has stopped working" displayed on DeleteSession

[florentbr]

On Windows, the driver doesn't properly quit Firefox which leads to a crash message box:

I found out that the driver doesn't terminate the process plugin-container.exe under firefox.exe.

Config:
Windows 8.1, Firefox 48.0.2, geckodriver-v0.10.0-win64, python client 3.0.0.b2

To reproduce:

from selenium.webdriver.firefox.service import Service
from selenium.webdriver.firefox.remote_connection import FirefoxRemoteConnection

# start service
service = Service("geckodriver.exe")
service.start()

# launch firefox
executor = FirefoxRemoteConnection(remote_server_addr=service.service_url)
sessionId = executor.execute('newSession', {})['sessionId']

# quit firefox
executor.execute('quit', {'sessionId': sessionId})  # Displays the dialog "Plugin Container for Firefox has stopped working"

Expected:

The driver should dispose all the processes under geckodriver.exe when the session is terminated.

[andreastt]

Does this happen consistently?

I have noticed frequent crashes on Linux when using officially branded builds, which leads me to suspect they are set up differently. However, I’m not sure yet if this is the cause.

[florentbr]

@andreastt, it happens when Firefox has the child process named plugin-container.exe. Previously this process was only present when the page had a plugin, like Flash. But since recently, this process is always present. I also noticed that this process is not present when Firefox starts with a blank page (about:blank) and present when Firefox starts with the home page (about:home), which is the case with v0.10.0.

I can also manually reproduce the same issue by just killing firefox.exe when the process plugin-container.exe is present.

[andreastt]

Thank you for the excellent explanation!

I don’t know why plugin-container.exe spawns when loading about:home, but I suspect what happens here is that we try to forcibly quit Firefox in geckodriver or that we interrupt the subprocess.

Either way we trigger crash detection which causes the dialogue you included a screenshot of on Windows, or a the Firefox crash dialogue on Windows that I’ve seen recently.

The fact that you pinpointed that this only seems to happen when on about:home was a very useful clue, because the immediate issue will get resolved by c49e5cd (coming in 0.11.0).

However, to solve the underlying issue I feel we should experiment with not using eForceQuit. Now that I know that calling quit whilst on about:home triggers this crash, I will try to find a solution.

[andreastt]

I could be mistaken about why I see the officially branded Firefox crash on my Linux system. The crash report it generates indicates there is something wrong with X syncing:

Without MOZ_X_SYNC:

[10505] ###!!! ABORT: X_ShmAttach: BadAccess (attempt to access private resource denied); 3 requests ago: file /builds/slave/m-rel-l64-00000000000000000000/build/src/toolkit/xre/nsX11ErrorHandler.cpp, line 157

With MOZ_X_SYNC:

[10856] ###!!! ABORT: X_SyncSetCounter: XSyncBadCounter; sync: file /builds/slave/m-rel-l64-00000000000000000000/build/src/toolkit/xre/nsX11ErrorHandler.cpp, line 157

I think this is unrelated to this issue as it also happens on starting Firefox, not on calling quitApplication in Marionette.

---

Edit: I’ve filed bug 1302500 about the things mentioned in this comment. It is not related to this GitHub issue.

[andreastt]

I just filed and patched bug 1302503 to allow GeckoDriver#quitApplication to take no parameters.

[florentbr]

@andreastt, I tried to send the command quitApplication directly to marionette with a session started with the gecko driver. The browser closes immediately without any issue and the child process plugin-container.exe is properly terminated:

import socket
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect(('127.0.0.1', 11174))
s.send(b'48:[0,1,"quitApplication",{"flags":["eForceQuit"]}]')
s.recv(1024)
s.close()

So the issue is probably not with marionette but with the gecko driver itself.

[avivasp]

My solution (Java source):

DesiredCapabilities desiredCapabilities = ...;
FirefoxProfile profile = new FirefoxProfile();
profile.setPreference("browser.startup.homepage","about:blank");
desiredCapabilities.setCapability(FirefoxDriver.PROFILE, profile);
WebDriver webDriver = new FirefoxDriver(desiredCapabilities);`

[ewdob]

Even though I have set the startup page to "about:blank", the plugin Container Error is still present for me. So I don't think this solution works for everybody.
If anybody has some other solutions I would be very grateful.

[andreastt]

@avivasp The homepage the browser starts on was corrected, as I said earlier in this thread, in c49e5cd which will be available in the next release of geckodriver.

Your fix only works incidentally because the default homepage in official branded Firefox builds causes the plugin container to be started for some reason. We are no closer to a real fix to this problem.

The next thing worth investigating is if the rust-mozrunner library is signalling the browser process in a way that causes the plugin container to error.

[ewdob]

I tried a run on a Windows 10 vm, and surprisingly the error didnt occur anymore.

[florentbr]

@andreastt, I managed to avoid the crash message by setting these environement variables:

SET MOZ_CRASHREPORTER=0
SET MOZ_CRASHREPORTER_DISABLE=1
SET MOZ_CRASHREPORTER_NO_REPORT=1
SET XRE_NO_WINDOWS_CRASH_DIALOG=1
REM SET GNOME_DISABLE_CRASH_DIALOG=1

I also defined these preferences to avoid the initial page which starts the plugin container:

user_pref("browser.startup.page", 0);
user_pref("browser.startup.homepage", "about:blank");
user_pref("browser.startup.homepage_override.mstone", "ignore");
user_pref("browser.usedOnWindows10", true);

[gerixx]

Now "firefox.exe" crashes when using quit() with Firefox 50.
Setting environment variable XRE_NO_WINDOWS_CRASH_DIALOG=1 avoids the dialog.

Log output:
Mozilla/5.0 (Windows NT 6.3; WOW64; rv:50.0) Gecko/20100101 Firefox/50.0
[Child 8756] ###!!! ABORT: Aborting on channel error.: file c:/builds/moz2_slave/m-rel-w32-00000000000000000000/build/src/ipc/glue/MessageChannel.cpp, line 2056
Nov 22, 2016 9:26:28 AM org.openqa.selenium.os.UnixProcess destroy
SEVERE: Unable to kill process with PID 7288

[iamcodylee]

I encounter this issue as well, but only on Windows 7
I use same scripts, same version Java, everything same except OS.
but surprisingly this issue only occur on Windows 7, not occur on Windows 8
also try to set the startup page to "about:blank"
the Plugin Container Error is still present on Windows 7

[neeasade]

Encountering @gerixx 's issue on Windows Server 2012 R2, Firefox 50. Also seeing OP's issue in Firefox 49 on the same OS.

[travisneedham]

I was getting this on both Win7 and Win10, using Gecko driver 0.14.0. For those of you struggling with this, but who do not require flash, disabling the flash plug-in worked for me:

profile.setPreference("plugin.state.flash", 0);

I am still getting the "Firefox has stopped working" message on Win7, but Win10 is totally cleared up now.

[JohnA2]

I don't have Win10 to test, but can confirm that disabling Flash in Firefox 52 running on Win7 doesn't help.

[andreastt]

I have taken @travisneedham’s advice and submitted #590 to disable Flash by default when using geckodriver. This only addresses the apparent fallout of the Aborting on channel error problem by preventing the plugin container to be used; it does not fix the underlying issue that calling Services.startup.quit in chrome JS forces a shutdown, which I believe I have addressed with https://bugzilla.mozilla.org/show_bug.cgi?id=1337743.

cc @mjzffr

[andreastt]

The latter issue, I should point is, is covered by #285.

[JohnA2]

I can confirm that I no longer see the error with the latest Firefox Nightly on Windows 7. Thanks @andreastt!

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you have run into an issue you think is related, please open a new issue.