Abstract the check for if a window supports protected media further into BrowserChild
Categories
(Core :: DOM: Content Processes, enhancement, P3)
Tracking
()
| 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
- A new IPC call that is used to perform the check.
- Two new functions on BrowserChild that are used to return a cached response and to set the cached response.
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.
|
Assignee | |
Comment 1•5 years ago
|
||
|
|
Assignee | |
Comment 2•5 years ago
|
||
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.
|
|
Assignee | |
Comment 3•5 years ago
|
||
Try run with what is hopefully the final iteration of the patch: https://treeherder.mozilla.org/#/jobs?repo=try&revision=3afb3d195864423b5d467c2068b95f0d0067e2b2
|
||
Comment 5•5 years ago
|
||
| bugherder | ||
Description
•