capturing a video stream of the currently selected tab



10 months ago
4 days ago


(Reporter: Andrei Skrykalov, Unassigned)


57 Branch

Firefox Tracking Flags

(firefox57 wontfix)




10 months ago
User Agent: Mozilla/5.0 (Windows NT 6.1; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/60.0.3112.113 Safari/537.36

Steps to reproduce:

var constraints = { video: { mediaSource: "browser" } };
  .then(stream => video.srcObject = stream)
  .catch(function(err) {console.log(err.message)});

Actual results:

we can't get a video stream of the currently selected tab

Expected results:

we got the stream and put it into video.srcObject

Comment 1

10 months ago
This is a continuing of the previous bug:


10 months ago
Component: Untriaged → WebExtensions: General
Product: Firefox → Toolkit


9 months ago
Severity: normal → enhancement
status-firefox57: --- → wontfix
Priority: -- → P5
Whiteboard: [design-decision-needed]
Hi Andrei, this has been added to the agenda for the February 13, 2018 WebExtensions APIs triage. Hope you'll be able to join us? 

Here’s a quick overview of what to expect at the triage: 

* We normally spend 5 minutes per bug
* The more information in the bug, the better
* The goal of the triage is to give a general thumbs up or thumbs down on a proposal; we won't be going deep into implementation details

Relevant Links: 

* Wiki for the meeting:
* Meeting agenda:
* Vision doc for WebExtensions:
Flags: needinfo?(lgreco)

Comment 3

4 months ago
I took a closer look at this and Bug 1396510 and the code in comment 0 is using a non-standard API which has never been available to a webpage (its original purpose was to be used internally by Firefox Hello) and so this is definitely not a bug but a feature request as we were originally assuming.

By looking at Bug 1396510 it seems that the discussion on the original bug has been focused on deciding if we could allow an extension to enable (and then use) a feature that was originally provided only to privileged code (and not to a regular web page).

Based on Bug 1396510 comment 12 and Bug 1396510 comment 13 it seems that we are likely going to provide this feature, but we would prefer to provide it through the new standard spec (instead of fixing the issues and add the missing pieces to a non-standard one, and I also definitely agree that it would be a better idea), and then eventually wrapping it in a chrome.tabCapture.capture API (if we also want/need to provide a Chrome-compatible API for it).

Given the strict relationship between this issue and Bug 1396510, this issue cannot be approved independently from the other one, to be fair I'm not sure that it is worth to keep this issue as separate from Bug 1396510 at this stage: given the comments mentioned above it is likely that we are not going to support this feature with the same API mentioned in Comment 0, and so we could just use Bug 1396510 to keep track of the design decision (and if it is approved then track its implementation in new follow up issues added as a dependency directly to Bug 1396510).
Flags: needinfo?(lgreco)

Comment 4

4 months ago
As described in Comment 3, this issue is highly dependent from the outcome of the "design decision" on Bug 1396510,
and so I've remove it from the "[design-design-needed]" whiteboard and I'm closing it as a duplicate of Bug 1396510.
Last Resolved: 4 months ago
Resolution: --- → DUPLICATE
Whiteboard: [design-decision-needed]
Duplicate of bug: 1396510


4 days ago
Product: Toolkit → WebExtensions
You need to log in before you can comment on or make changes to this bug.