Screen selection broken using WebAPI with Firefox 93+
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
Tracking | Status | |
---|---|---|
firefox-esr78 | --- | unaffected |
firefox-esr91 | --- | unaffected |
firefox92 | --- | unaffected |
firefox93 | --- | wontfix |
firefox94 | --- | wontfix |
People
(Reporter: resteve, Unassigned)
References
(Regression)
Details
(Keywords: regression)
Comment hidden (obsolete) |
Reporter | ||
Comment 1•3 years ago
|
||
Steps to reproduce:
The following code snippet doesn't work to select screen device.
navigator.mediaDevices.getUserMedia({ video: { mediaSource: 'screen' } })
Actual results:
Console error:
Uncaught (in promise) DOMException: Display capture requires transient activation from a user gesture.
Expected results:
Screen selection window pops up.
Reporter | ||
Comment 2•3 years ago
|
||
Last comment stands. As a matter of fact there was no code to make it working, but the constraint was not processed when using a non-existing field MediaSource. Therefore default camera device came up instead.
Comment 3•3 years ago
|
||
The Bugbug bot thinks this bug should belong to the 'Core::DOM: Core & HTML' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.
Comment 4•3 years ago
|
||
Base on hg log history, I think WebRTC: Audio/Video
might be a proper component, feel free to bounce it back if I was wrong.
Comment 5•3 years ago
|
||
I can confirm this in 94, and also that it does not happen in 91 or 92.
Comment 6•3 years ago
|
||
mozregression produces: https://hg.mozilla.org/integration/autoland/pushloghtml?fromchange=3778bee8e0f8081a70782163fc54d238ebee21a1&tochange=3d86317782d298b98be58646114bebba21611014
Bug 1705289 - Karl, is it expected that different case gives different results?
Comment 7•3 years ago
|
||
Thank you for the clear report.
This was an expected behavior change to align the behavior of the legacy experimental mediaSource: 'screen'
API with that of the standard-track getDisplayMedia()
API. getDisplayMedia()
requires a recent user gesture (transient activation) to provide some evidence that the user is actively engaged with the document at the time the request for display media is presented, which is a requirement introduced due to the potentially sensitive nature of the data exposed.
This is consistent with the behavior intended for Safari. Does your use case have a solution that works with WebKit browsers?
(In reply to Michael Froman [:mjf] from comment #6)
Bug 1705289 - Karl, is it expected that different case gives different results?
Yes, the dictionary member keys are case-sensitive. See comment 2, which corrected comment 0.
Updated•3 years ago
|
Updated•3 years ago
|
Updated•3 years ago
|
Comment 8•3 years ago
|
||
Set release status flags based on info from the regressing bug 1705289
Reporter | ||
Comment 9•3 years ago
|
||
Thanks for the clarification Karl.
The problem for us is that we are executing that code snippet directly instead of it being triggered from an interaction with the UI.
We'll try to work around it, but is there any Firefox flag that could disable this new restriction?
Comment 10•3 years ago
|
||
(In reply to Ruben Esteve from comment #9)
is there any Firefox flag that could disable this new restriction?
There is no option for the user to bypass the transient activation check, sorry.
(Test frameworks using webdriver typically use a click for this, but I assume that is not what you are wanting.)
Comment 11•3 years ago
|
||
Karl, should the state of the bug be moved to INVALID? Since it is an expected behavior, can the regression flag be removed?
Reporter | ||
Comment 12•3 years ago
|
||
I guess this bug can be closed then. We'll have to find a solution in our test harness along the lines of what's been suggested (using a click or something). Thanks.
Comment 13•3 years ago
|
||
I think the regression flag is appropriate as the bug is describing what appears to be a regression from some perspective.
Technically I guess INVALID is specified because intended behavior is not considered a bug. However I'd prefer WONTFIX for a valid report on a breaking change in behavior with an explicit decision not to fix. (We might still reconsider this decision if a serious break in a common use case were to come to light.)
For testing, we also have SpecialPowers.wrap(document).notifyUserGestureActivation()
. I don't know exactly how our test harness enables SpecialPowers
Reporter | ||
Comment 14•3 years ago
|
||
Karl, is there any way we can also use SpecialPowers? Is it a publicly available library?
Comment 15•3 years ago
•
|
||
SpecialPowers is loaded as an extension. The code is open source and so I assume it could be extracted and used in your Firefox testing, but I'm not aware of recent cases of people doing this.
I suspect WebDriver/geckodriver/Marionette would provide a more versatile, and probably better supported, testing framework, which would include click support, making SpecialPowers unnecessary for this purpose.
At the other end of options, the "dom.user_activation.transient.timeout" pref might be set to a large number so that a single click from a user starting a test might be sufficient for all getUserMedia()
calls occurring in a single document. Another user interaction, however, would be required for each document loaded.
Updated•3 years ago
|