Fix GetTopLevelContentDocument() usage in MediaDevices code
Categories
(Core :: WebRTC: Audio/Video, defect)
Tracking
()
Fission Milestone | Future |
People
(Reporter: kmag, Unassigned, NeedInfo)
References
Details
This code attempts to check if the top-level content document is focused, and denies the request if it isn't. Since GetTopLevelContentDocument
only considers in-process ancestors, though, it won't do the right thing for OOP subframes. I don't think it will ever return false positives, but I do think it will return false negatives for OOP subframes where the top-level document has focus but the OOP frame (or a same-origin ancestor) doesn't.
Comment 2•4 years ago
|
||
GetTopLevelContentDocument()
is undocumented, but uses IsTopLevelContentDocument()
, which is also undocumented.
Assuming IsTopLevelContentDocument()
is dependable, GetTopLevelContentDocument()
would return nullptr if the toplevel content document is in a different process.
In that case, eUseCounter_custom_EnumerateDevicesUnfocused
would not be bumped with a cross-site toplevel even if the toplevel were unfocused.
This is a permanent data collection and was added for bug 1397978.
nsFocusManager
doesn't look helpful, which means that BrowsingContext::CanFocusCheck()
with limited documentation would also not be helpful.
I suspect the missing counts from cross-site documents would be of small significance, particularly with default feature allowlist of "self".
Jan-Ivar, just checking: are we still wanting to keep this telemetry for bug 1397978?
Updated•4 years ago
|
Comment 3•4 years ago
|
||
Nika, can you please assess comment 2 for an appropriate Fission milestone assignment.
Comment 4•4 years ago
|
||
This is only impacting a perf counter which it is unclear if we're depending on. If :jib determines we still care about the perf counter someone can fix this issue, otherwise, I don't think this should block MVP.
Updated•1 year ago
|
Description
•