Chrome Web Store decided to disable inline-installation of extensions for Chrome. This is directly related to WebRTC-applications, because now for screening in Chrome you need an extension. Will the
getDisplayMedia API come to the rescue?
Chrome Screenshot
When this feature
appeared in Chrome 33 , its work required an extension — to solve security problems. This method is better than the previous one, when the screenshots were hidden under the flag, which is why websites asked users to activate this flag ... Which led to
public security messages .
Chrome has not changed much since 2013. Expansion requirements added difficulties to the sharing process, but thanks to the
inline installation , which simplified life:
- the user clicks the button to start screenshoting;
- the web application determines that Chrome is being used and that the extension is not installed;
- the web application launches the inline installation, successfully resolves the callback;
- In Chrome, a window pops up choosing what the user wants to share.
Details of the implementation can be
found here .
The selection window is the key element here. Is it safe to use it without the Web Store?
In this case, the sharing of the tab is especially perplexing, because it violates the sandbox principle for “cross-origin” scenarios.
Screenshoting in Firefox
Firefox has a different approach — whitelisting sites who are allowed to use the API. To be included in this list, the site must make a request to Mozilla and show that it contains the Terms of Service (terms of service) and Privacy Policy (privacy policy). You can change the whitelist using the extension. The need for such a list disappeared with the release of Firefox 52, when any confirmed source was allowed to use screenshots. It still does not use the new
getDisplayMedia API , about which we will soon tell, but the implementation is almost the same:
| navigator.mediaDevices.getUserMedia({video: {mediaSource: 'screen'}}) |
| .then(stream => { |
| // , |
| videoElement.srcObject = stream; |
| }, error => { |
| console.log(" ", error); |
| }); |
As a result, the implementation will be modified
to match the specification .
getDisplayMedia API
The W3C consortium is working on standardizing the
screen capture API. It is relatively simple and based on promises, like
getUserMedia :
| // 1 Screen Capture API |
| navigator.getDisplayMedia({ video: true }) |
| .then(stream => { |
| // , |
| videoElement.srcObject = stream; |
| }, error => { |
| console.log(" ", error); |
| }); |
Microsoft EDGE has already rolled out a screenshot this year. The use case is thought out quite well, with the addition of a yellow frame around the area the user is sharing:
Screenshot window in Edge. Pay attention to the yellow frame, which highlights what exactly is shared.Times change, and Chrome extensions with them
Speaking of user experience, the extensions appear.in works as described above and has over a million installations. The vast majority of users came through an inline installation, and there are so many of them that the screenshots of the extension in the Chrome Web Store have not been updated since ... probably 2014.
As
stated in the Chrome Web Store blog , they are now cutting out the inline installation. This was a big surprise, the first time I learned about this thanks to the old Chrome problem - to make screenshots more accessible (thanks to
Wilhelm Wanecek for the tip).
If I understand correctly, this will lead to the fact that the Chrome Web Store will open in a separate tab. From the side of the web application, it will become more difficult to determine when the user has installed the extension, you will have to use polls or timeout. The following terms are indicated in the post:
- inline installation will not be available for new extensions starting from June 12th. No advance notice;
- for already published extensions inline-installation will be available until September 12. Advance notice - for three months.
Claims
There are definitely problems here. And I'm not even talking about Google Hangouts / Meet, which completely avoids the difficulties with the UX, which everyone else has to contend with using the built-in extension. Chrome guys are
already twisting their arms .
I would like to receive some news in advance from the Chrome Web Store team (the letter arrived about 24 hours after the blog post). The extensions appear.in more than a million users, which makes this extension one of the most popular for screening. Our users trust our site, namely, they give us access to their microphones and cameras. Using inline installations based on this trust is probably safer than installing from the Chrome Web Store. We also turned to the support of the Web Store to remove illegal copies of the extension, which hundreds of users have set themselves repeatedly.
And it would be great if the guys from Google warned us.
The
@webrtc account mentioned its intention to roll out
getDisplayMedia in response to changes in inline-installation policy.
The path for Chrome is the release of
getDisplayMedia . “The intention to roll out” was published
shortly after the main news . However, given the release of Chrome, it will take several weeks. This is a non-trivial change in security regulations and user scenarios, so it is doubtful that it will occur before September 12 deadline. The branch point for Chrome 69, which will be released by September 12, within one month.
The situation with Chrome is complicated by the fact that tab sharing is now allowed, but with limited display choices for the user. Audio output sharing is supported in Chrome, but it is not even in the
getDisplayMedia specification.
How to prepare for changes in Chrome
The code related to
getDisplayMedia support is relatively uncomplicated. Typically, the call to this API is the same as
getUserMedia is
called with the argument
mediaSource in Firefox. Determining whether this feature is available is easy, you need to check if
getDisplayMedia exists and use it in priority when available:
It is still not entirely clear how to specify the frame rate. Using
applyConstraints in the returned
MediaStreamTrack works for
getUserMedia and is likely to work for
getDisplayMedia :
| navigator.getDisplayMedia({video: true}) |
| .then(stream => { |
| stream.getTracks()[0].applyConstraints({frameRate: 5}); |
| return stream; |
| }) |
Details are in the
bugtracker specs .
Alas,
adapter.js cannot insert
getDisplayMedia , since the interaction with each extension is implemented a little differently.
Further and higher
I watch closely if WebRTC developers from Google can influence the inline-installation deadline or roll out
getDisplayMedia on time. Development under the web is sometimes messy, yes, but as a rule at the end we see a good result. We are waiting for the end of this story and we will be glad to say goodbye to our extensions.
Screenshot of Voximplant
We also have a screenshot that works successfully in Chrome. However, while no one has said goodbye to the extensions, you need to do the following:
- Download extension from our repository: github.com/voximplant/voximplant-chrome-extension
- Go to the folder where the extension is downloaded, open manifest.json and add the URL of your site to the matches section.
- In the new Chrome tab, enter chrome: // extensions , enable developer mode and load the extension from the folder.
So you install the dev version of the extension. For end users it will be more convenient if you publish the extension in the Googe Web Store. About this, as well as how to use screenshots on our platform, you can read in
our How-to . Good sharing to you!