Skip to content
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 · 8 comments
Closed

Support Firefox with e10s enabled #43

EricRahm opened this issue Jan 23, 2016 · 8 comments

Comments

@EricRahm
Copy link

@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
Copy link
Member

@jgraham 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
Copy link
Author

@EricRahm 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
Copy link
Contributor

@andreastt 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
Copy link
Contributor

@AutomatedTester 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
Copy link
Contributor

@andreastt 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
Copy link
Member

@jgraham 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
Copy link
Member

@jgraham 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.

@lock
Copy link

@lock lock bot commented Aug 17, 2019

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.

@lock lock bot locked and limited conversation to collaborators Aug 17, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
4 participants