Closed Bug 1586347 Opened 5 years ago Closed 5 years ago

Abstract the check for if a window supports protected media further into BrowserChild

Categories

(Core :: DOM: Content Processes, enhancement, P3)

enhancement

Tracking

()

RESOLVED FIXED
mozilla71
Tracking Status
firefox71 --- fixed

People

(Reporter: bryce, Assigned: bryce)

References

Details

Attachments

(1 file)

Bug 1581855 added functionality on BrowserChild to check if the window the BrowserChild is in supports protected media or not. This is done via

Currently the consumers of this functionality interact with all 3 of these functions, as here. I think we could refactor this so that consumers only interact with a single call, DoesWindowSupportProtectedMediaCheck, which can return a promise, and the BrowserChild can hide the caching logic and resolve the promise once it has the required information. This creates a simpler surface for callers for a small performance trade off -- the call would always go via a MozPromise, where as in the current cached path we will not. Since this isn't a hot path or one that needs high performance, I think the simpler interface worth it.

Currently when checking if a window supports protected media it's up to the
caller interacting with a BrowserChild to check if a response is already
cached, to perform the check if needed, and to then set the cached response if a
call was made. This patch moves that logic internal to Browser child so that
callers need to only worry about interacting with a single function.

Pushed by bvandyk@mozilla.com:
https://hg.mozilla.org/integration/autoland/rev/8ea163ea6721
Have BrowserChild internally take care of caching logic when checking if windows support protected media. r=dminor,rhunt
Status: NEW → RESOLVED
Closed: 5 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla71
Regressions: 1601988
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: