WebDriver browser configuration (like environment variables) are not forwarded to the pytestrunner
Categories
(Testing :: web-platform-tests, defect, P1)
Tracking
(firefox120 fixed)
| Tracking | Status | |
|---|---|---|
| firefox120 | --- | fixed |
People
(Reporter: whimboo, Assigned: whimboo)
References
(Blocks 2 open bugs)
Details
(Whiteboard: [webdriver:m8], [wptsync upstream])
Attachments
(4 files)
Environment variables are currently not forwarded to the pytestrunner. As such our Mozilla specific tests do not run with the MOZ_DISABLE_NONLOCAL_CONNECTIONS environment variable set and causing crashes when trying to get async events working with Wdspec (see bug 1852243).
| Assignee | ||
Comment 1•2 years ago
|
||
This is actually not only for environment variables but basically related to a lot of the browser configuration arguments.
For the public WdSpec tests the webdriver binary gets started by the FirefoxWdSpecBrowser (WebDriverBrowser) class.
But for Mozilla specific tests we start another instance of geckodriver via the GeckoDriver fixture. And here we would have to pass the extra information like environment settings via the pytestrunner and WdspecExecutor.
It looks like that we might have to subclass WdspecExecutor to have a WdspecFirefoxExecutor class specific for Firefox (similar for Android), so that we can pass all the arguments from the FirefoxWdSpecBrowser class as well. Otherwise we miss a lot of those arguments and start Firefox with incorrect settings.
Given that this sounds like a larger refactoring I would like to hear the feedback from James, or let it get discussed in next weeks triage meeting. Maybe we can find a quick solution for environment variables?
| Assignee | ||
Updated•2 years ago
|
Comment 2•2 years ago
|
||
This allows it to be used in fixtures that directly control processes.
Updated•2 years ago
|
Comment 3•2 years ago
|
||
I imagine something like the patch attached will work? I haven't extensively tested it though (and for some reason try didn't run any jobs).
| Assignee | ||
Updated•2 years ago
|
Comment 4•2 years ago
|
||
https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=Pc8DVyfQTUafrwUlUW9tvw.0&revision=7897f3711204e2735d5cf35d9cba90b10b5edb3c is now running and we do indeed get some new crashes with this patch due to passing in the disabled network connections.
| Assignee | ||
Comment 5•2 years ago
|
||
| Assignee | ||
Updated•2 years ago
|
| Assignee | ||
Comment 6•2 years ago
|
||
(In reply to James Graham [:jgraham] from comment #4)
https://treeherder.mozilla.org/jobs?repo=try&selectedTaskRun=Pc8DVyfQTUafrwUlUW9tvw.0&revision=7897f3711204e2735d5cf35d9cba90b10b5edb3c is now running and we do indeed get some new crashes with this patch due to passing in the disabled network connections.
The problem here was with the profile root test, where geckodriver itself creates a new profile but doesn't have a reference to the default profile. As such only the recommended preferences are set and not those from the wpt's user.js file. The extra revision that I just pushed fixes the problem.
| Assignee | ||
Updated•2 years ago
|
Comment 7•2 years ago
|
||
Updated•2 years ago
|
Comment 9•2 years ago
|
||
| bugherder | ||
https://hg.mozilla.org/mozilla-central/rev/43c06d6ece96
https://hg.mozilla.org/mozilla-central/rev/cd110eb5314b
https://hg.mozilla.org/mozilla-central/rev/6ce94024661c
| Assignee | ||
Comment 11•2 years ago
|
||
Comment 12•2 years ago
|
||
Comment 13•2 years ago
|
||
| bugherder | ||
Description
•