Skip to content
This repository has been archived by the owner on Nov 6, 2019. It is now read-only.

Pass browser-specific command line flags when running webrtc/ #125

Open
foolip opened this issue Sep 27, 2017 · 12 comments
Open

Pass browser-specific command line flags when running webrtc/ #125

foolip opened this issue Sep 27, 2017 · 12 comments

Comments

@foolip
Copy link
Member

foolip commented Sep 27, 2017

http://wpt.fyi/webrtc is almost entirely red, often because getUserMedia() needs permissions and user interaction. Example: http://wpt.fyi/webrtc/simplecall.html

This is obscuring the “real” status of the tests, and makes it impossible for @guidou, @henbos and other implementers to effectively use the dashboard to prioritize their work.

The "proper" fix for this is:

However, this will at earliest be done some time in early 2018. We should get useful results for the webrtc/ directory ASAP, and then work on paying back that technical debt.

@jgraham FYI. If this will require some changes in wpt runner I hope you think the above approach makes sense.

@patrickkettner @jan-ivar @youennf, we may need your help in picking the right set of command line flags for Edge, Firefox and Safari. Or @agouaillard, you know them, can paste them here?

@foolip foolip changed the title Pass browser-specific command line flags when running webrtc/ for wpt.fyi Pass browser-specific command line flags when running webrtc/ Sep 27, 2017
@agouaillard
Copy link

agouaillard commented Sep 27, 2017 via email

@youennf
Copy link

youennf commented Sep 27, 2017

Safari version would need to be upgraded first to Safari 11 or STP.
The script @agouaillard mentioned should work for Safari11.
For STP, it might be good to use some recently added WebDriver options.

@agouaillard
Copy link

agouaillard commented Sep 27, 2017 via email

@foolip
Copy link
Member Author

foolip commented Sep 27, 2017

Thanks @agouaillard, that's very helpful.

@JKereliuk, I think the minimum set of flags for Chrome would be --use-fake-ui-for-media-stream and --use-fake-device-for-media-stream, corresponding to the two WebDriver extensions that are needed.

@youennf, we'd love to have Safari 11 or STP as part of the dashboard. Having them available on Sauce would fix that. I've reached out to y'all over email again.

@rwaldron
Copy link
Contributor

This is excellent—I will do whatever I can to be helpful and offer myself as a resource in achieving these goals.

@kereliuk
Copy link
Collaborator

@agouaillard @youennf I'm not sure which options you are talking about?
You can pass capabilities to ChromeDriver, or you can pass browser options to the chromeOptions object. Which (if either) do you mean?

@jgraham
Copy link
Collaborator

jgraham commented Sep 27, 2017

I wonder if it is possible to add the firefox prefs to http://searchfox.org/mozilla-central/source/testing/profiles/prefs_general.js; we already apply those testing prefs when running wptrunner.

Otherwise, if you only want to apply these prefs to the WebRTC tests, the easiest way is to set up the dashboard with some metadata ini files. We already support setting Fx prefs like [1], and I feel like I might have implemented passing binary args at some point for servo, and could certainly make that work for other browsers.

[1] http://searchfox.org/mozilla-central/source/testing/web-platform/meta/webrtc/__dir__.ini#1

@agouaillard-cosmo
Copy link

agouaillard-cosmo commented Sep 27, 2017

@JKereliuk , @youennf is speaking about safari. I'm speaking about chrome.

We use chromeOptions -> addArgument( ) for each command line flag:

switch (browser.getBrowserName()) {
      case "chrome":
        ChromeOptions chromeOptions = new ChromeOptions();
        chromeOptions.addArguments("use-fake-ui-for-media-stream");
        chromeOptions.addArguments("use-fake-device-for-media-stream");
        capabilities.setCapability(ChromeOptions.CAPABILITY, chromeOptions);
        break;
      case "firefox":
        FirefoxProfile firefoxProfile = new FirefoxProfile();
        firefoxProfile.setPreference("media.navigator.streams.fake", true);
        FirefoxOptions firefoxOptions = new FirefoxOptions();
        firefoxOptions.setProfile(firefoxProfile);
        capabilities.merge(firefoxOptions.toCapabilities());
        break;
      case "MicrosoftEdge":
        capabilities.setCapability("avoidProxy", true);
        break;
      case "safari":
        SafariOptions options = new SafariOptions();
        options.setUseTechnologyPreview(true);
        capabilities.setCapability(SafariOptions.CAPABILITY, options);
        break;
    }

@foolip
Copy link
Member Author

foolip commented Oct 4, 2017

web-platform-tests/wpt#7424 is relevant to this as well.

@foolip
Copy link
Member Author

foolip commented Oct 18, 2017

We should probably include https://wpt.fyi/mediacapture-streams as well, since it would be trivial.

@foolip
Copy link
Member Author

foolip commented Apr 13, 2018

@kereliuk, this is now done for Chrome, but not Firefox, right?

@jugglinmike
Copy link
Collaborator

@kereliuk, this is now done for Chrome, but not Firefox, right?

The results collector currently specifies the parameters mentioned above, and, Chrome is reported as passing some WebRTC tests on wpt.fyi. Chrome continues to fail most WebRTC tests, but this matches my experience when manually executing tests hosted on w3c-test.org. Still, I'm not sure if this is an accurate reflection of the implementation status or another issue with the testing environment.

@foolip: to close this issue, I'd like to get confirmation from a Chromium implementer. Could you introduce me to someone who could sign off on the accuracy of the results?

Firefox:

all through profiles, the main options are:

  • media.navigator.streams.fake
  • media.navigator.permission.disabled

I've attempted to set these commands on a "headless" Ubuntu system running Firefox 59.0.2:

xvfb-run --auto-servernum \
  ./wpt run --include webrtc/RTCDTMFSender-ontonechange-long.https.html \
    firefox \
    --setpref 'media.navigator.streams.fake=true' \
    --setpref 'media.navigator.permission.disabled=true'

But that test continues to time out in the environment. This conflicts with the results I receive when running the same browser from my development system and manually visiting https://w3c-test.org/webrtc/RTCDTMFSender-ontonechange-long.https.html, so I suspect there is something else I am missing. @agouaillard do you have any thoughts on this? Can you suggest a Firefox implementer that I could speak with on the topic?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests

9 participants