New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Support Firefox with e10s enabled #43

Closed
EricRahm opened this Issue Jan 23, 2016 · 7 comments

Comments

Projects
None yet
4 participants
@EricRahm

EricRahm commented Jan 23, 2016

In order to make progress on testing e10s-enabled Firefox I added some prefs to marionette.js. After launching the browser I was unable to interact with it, which is a bit surprising as marionette itself does support e10s.

Enable e10s patch:

diff --git a/src/marionette.rs b/src/marionette.rs
index 66da6c1..bbc3f65 100644
--- a/src/marionette.rs
+++ b/src/marionette.rs
@@ -151,7 +151,7 @@ impl ToMarionette for GeckoContextParameters {
     }
 }

-pub static FIREFOX_PREFERENCES: [(&'static str, PrefValue); 50] = [
+pub static FIREFOX_PREFERENCES: [(&'static str, PrefValue); 55] = [
     ("app.update.auto", PrefValue::PrefBool(false)),
     ("app.update.enabled", PrefValue::PrefBool(false)),
     ("browser.displayedE10SPrompt.1", PrefValue::PrefInt(5)),
@@ -169,8 +169,13 @@ pub static FIREFOX_PREFERENCES: [(&'static str, PrefValue); 50] = [
     ("browser.sessionstore.resume_from_crash", PrefValue::PrefBool(false)),
     ("browser.shell.checkDefaultBrowser", PrefValue::PrefBool(false)),
     ("browser.startup.page", PrefValue::PrefInt(0)),
-    ("browser.tabs.remote.autostart.1", PrefValue::PrefBool(false)),
-    ("browser.tabs.remote.autostart.2", PrefValue::PrefBool(false)),
+    ("browser.tabs.remote.autostart.1", PrefValue::PrefBool(true)),
+    ("browser.tabs.remote.autostart.2", PrefValue::PrefBool(true)),
+    ("browser.tabs.remote.autostart.3", PrefValue::PrefBool(true)),
+    ("browser.tabs.remote.autostart.4", PrefValue::PrefBool(true)),
+    ("browser.tabs.remote.autostart.5", PrefValue::PrefBool(true)),
+    ("browser.tabs.remote.autostart.6", PrefValue::PrefBool(true)),
+    ("dom.ipc.processCount", PrefValue::PrefInt(1)),
     ("browser.tabs.warnOnClose", PrefValue::PrefBool(false)),
     ("browser.tabs.warnOnOpen", PrefValue::PrefBool(false)),
     ("browser.warnOnQuit", PrefValue::PrefBool(false)),

Reduced test:

from selenium import webdriver
from selenium.webdriver.common.keys import Keys
from selenium.webdriver.common.desired_capabilities import DesiredCapabilities

firefox_capabilities = DesiredCapabilities.FIREFOX.copy()
firefox_capabilities['marionette'] = True
firefox_capabilities['binary'] = '/Applications/FirefoxNightly.app/Contents/MacOS/firefox'
driver = webdriver.Firefox(capabilities=firefox_capabilities)
# Load a dummy page
driver.get('data:text/html,Hello World!')
# Try to open a tab
self.driver.find_element_by_tag_name('body').send_keys(Keys.COMMAND + "t")
@jgraham

This comment has been minimized.

Collaborator

jgraham commented Jan 25, 2016

I'm not sure what the right way of supporting this is. Should it inspect the capabilities to see whether to launch Fx with e10s or not? @AutomatedTester @andreastt ?

@EricRahm

This comment has been minimized.

EricRahm commented Jan 26, 2016

@jgraham Just being able to set it with prefs would probably be fine, but we currently can't do that (see issue #27). Having an e10s capability would be fine too.

The bigger issue is that when e10s is enabled I wasn't actually able to interact with the browser via wires. For the time being I've worked around this by creating a marionette test case and using that directly instead.

@andreastt

This comment has been minimized.

Member

andreastt commented Jan 26, 2016

Neither Selenium or the WebDriver specification mandates how user agents ought to be instrumented, but the two common ways are through profiles and capabilities which get translated into profile preferences.

I think in this case we want to be able to pass a custom profile to wires and have that produce a union of suggested preferences. For example, if the given preference list contains an entry foo but the suggested list in wires doesn’t, foo is included. If bar is defined by the client as well as wires, the client preference trumps the suggested default value in wires.

This would let wires switch on (or off) e10s by default, but respect the idiosyncrasies of the preferences in the profile the user provides.

@AutomatedTester

This comment has been minimized.

Member

AutomatedTester commented Jan 26, 2016

We definitely need a mechanism to allow people to allow people to create
their own profiles and pass it in. In ChromeDriver they have a client side
concept called Options[1] that translate into capabilities and then the
server extracts a set few, like extensions, and builds a profile and starts
the browser with this new profile laid out on disk.

[1] https://sites.google.com/a/chromium.org/chromedriver/capabilities

David Burns
Email: david.burns@theautomatedtester.co.uk
URL: http://www.theautomatedtester.co.uk/

On Tue, Jan 26, 2016 at 11:57 AM, Andreas Tolfsen notifications@github.com
wrote:

Neither Selenium or the WebDriver specification mandates how user agents
ought to be instrumented, but the two common ways are through profiles and
capabilities which get translated into profile preferences.

I think in this case we want to be able to pass a custom profile to wires
and have that produce a union of suggested preferences. For example, if the
given preference list contains an entry foo but the suggested list in
wires doesn’t, foo is included. If bar is defined by the client as
well as wires, the client preference trumps the suggested default value in
wires.

This would let wires switch on (or off) e10s by default, but respect the
idiosyncrasies of the preferences in the profile the user provides.


Reply to this email directly or view it on GitHub
#43 (comment).

@andreastt

This comment has been minimized.

Member

andreastt commented Jan 26, 2016

I can’t find anything in the WebDriver specification on how to deal with vendor-specific capabilities, but providing some subset of short-hand capabilities that affect preferences in the profile wires creates makes some sense.

For example it will be necessary to be able to set the Firefox binary location and flags through capabilities, as the wires binary may not live on the same machine as the client, and may be served behind a RemoteWebDriver intermediary node. It would also be good not to break the existing FirefoxDriver interface that allows you to serialise and pass entire profiles including extensions across the wire.

However, I think it’s more important right now to focus on the primitives. Allowing wires to take a profile as a capability will solve the immediate problems at hand. Figuring out the user-facing APIs in the clients is, I think, somewhat out of scope here.

@jgraham

This comment has been minimized.

Collaborator

jgraham commented Mar 11, 2016

We now have an intermediate solution where you can pass --e10s when starting wires to get e10s prefs set. It will not be too hard to work this into a capability.

@jgraham

This comment has been minimized.

Collaborator

jgraham commented Jul 21, 2016

I changed this to --no-e10s in the clap branch and have implemented the ability to pass a profile (and also prefs but not landed yet), so I think this is basically fixed.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment