1576915 - Port PictureInPictureChild and PictureInPictureToggleChild message manager actors to JSWindowActors

Status: RESOLVED FIXED

(Toolkit :: Video/Audio Controls, task, P3)

Description

[Mike Conley (:mconley) (:⚙️)]

This is a project we're hoping to point at an MSU student for the Fall semester.

For PictureInPictureChild:

Here's the actor definition: https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/toolkit/modules/ActorManagerParent.jsm#297-310

and the implementation: https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/toolkit/actors/PictureInPictureChild.jsm#690-961

For PictureInPictureToggleChild:

Here's the actor definition: https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/toolkit/modules/ActorManagerParent.jsm#312-321

and the implementation: https://searchfox.org/mozilla-central/rev/325c1a707819602feff736f129cb36055ba6d94f/toolkit/actors/PictureInPictureChild.jsm#47-689

Comment 1

[bayyatej.dev]

Attachment: Bug 1576915 Partial Port of Picture in Picture to JSWindowActors using async player workaround

Comment 2

[bayyatej.dev]

Attachment: Bug 1576915 remove incomplete port of PictureInPictureToggleChild and achieve video cloning thru this.docshell.messageManager

Comment 3

[Mike Conley (:mconley) (:⚙️)]

Hey nika,

So this is the bug where Teja is attempting to port PictureInPictureChild to JSWindowActors. Like I mentioned yesterday, part of the issue seems to be the WindowGlobalParent getting swapped out early in the lifetime of the remote <browser> that hosts the cloned video, because it's getting explicitly navigated to about:blank.

You mentioned yesterday that we can avoid that extra about:blank load by setting nodefaultsrc to true on the <browser>, and not actually navigating it anywhere - and you're right, this means that the first WindowGlobalParent we get from it doesn't change, and we can reliably send messages through to the child-side. Great!

The problem now seems to be that this initial about:blank that's loaded in the remote browser doesn't seem to want to display anything. The inner window itself reports having appropriate dimensions, but the underlying document element and document body resolve to having 0 width and 0 height, so nothing is displayed.

Any ideas what we can do about that? Note that by loading another document in that frame, we do get that document showing up (but then we get the problem of the swapped out WindowGlobalParent that we started with).

Comment 4

[:Gijs (he/him)]

(In reply to Mike Conley (:mconley) (:⚙️) from comment #3)

The problem now seems to be that this initial about:blank that's loaded in the remote browser doesn't seem to want to display anything. The inner window itself reports having appropriate dimensions, but the underlying document element and document body resolve to having 0 width and 0 height, so nothing is displayed.

Any ideas what we can do about that? Note that by loading another document in that frame, we do get that document showing up (but then we get the problem of the swapped out WindowGlobalParent that we started with).

Apologies for the driveby, but this sounds suspiciously similar to what kmag was saying in https://bugzilla.mozilla.org/show_bug.cgi?id=1582788#c1 .

Comment 5

[bayyatej.dev]

Attachment: Bug 1576915 Port PiPToggle to JSWindowActors

Comment 6

[bayyatej.dev]

Attachment: Bug 1576915 Port of Picture in Picture to JSWindowActors

Comment 7

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/2012ad5d5af4
Port of Picture in Picture to JSWindowActors r=mconley

Comment 8

[Dorel Luca [:dluca]]

https://hg.mozilla.org/mozilla-central/rev/2012ad5d5af4

Comment 9

[Chris Peterson [:cpeterson]]

Retroactively moving fixed bugs whose summaries mention "Fission" (or other Fission-related keywords) but are not assigned to a Fission Milestone to an appropriate Fission Milestone.

This will generate a lot of bugmail, so you can filter your bugmail for the following UUID and delete them en masse:

0ee3c76a-bc79-4eb2-8d12-05dc0b68e732