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 4 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•1 year 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•1 year ago
|
Comment 2•1 year ago
|
||
This allows it to be used in fixtures that directly control processes.
Updated•1 year ago
|
Comment 3•1 year 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•1 year ago
|
Comment 4•1 year 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•1 year ago
|
||
Assignee | ||
Updated•1 year ago
|
Assignee | ||
Comment 6•1 year 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•1 year ago
|
Comment 7•1 year ago
|
||
Updated•1 year ago
|
Comment 9•1 year 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•1 year ago
|
||
Comment 12•1 year ago
|
||
Comment 13•1 year ago
|
||
bugherder |
Description
•