1524065 - Use browsing context to notify content tab to resume delayed autoplay media

Status: VERIFIED FIXED

(Core :: Audio/Video: Playback, enhancement, P2)

Description

[Alastor Wu [:alwu]]

This bug will use the browsing context to notify content tab to resume delayed autoplay media, instead of using MessageManager.

If we don't do so, we're not able to resume media in the different process when we we enable Fission, because the current way we use can only notify one process and would cause the media on other process can't be resumed.

Comment 1

[Alastor Wu [:alwu]]

Attachment: Bug 1524065 - part1 : implement the way to resume delayed autoplay media via browsing context.

After enable Fission, we're not able to resume media in the different process, because the current way we use can only notify one process and would cause the media on other process can't be resumed.

Therefore, we should use the browsing context to notify the web content which might be on different processes.

Comment 2

[Alastor Wu [:alwu]]

Attachment: Bug 1524065 - part2 : use browsing context to resume delayed autoplay media.

Replace the current way and use the new way.

Comment 3

[Alastor Wu [:alwu]]

Attachment: Bug 1524065 - part3 : remove unused message.

resumeMedia is used for resuming delayed autoplay, which have been replaced by notifying via the browsing context.

Comment 4

[Alastor Wu [:alwu]]

Not sure if mentioning someone in the phabricator will send the notication, so this NI is used for notification in case missing the comment [1]

[1] https://phabricator.services.mozilla.com//D18136#486285

Comment 5

[Andreas Farre [:farre]]

Right, so I've landed the patch today. Hopefully it sticks. Now you should be able to do:

void ChromeBrowsingContext::NotifyStartDelayedAutoplayMedia() {
  // This will send the message to all processes that have 'this'
  for (auto iter = Group()->ContentParentIter(); !iter.Done(); !iter.Next()) {
    auto entry = iter.Get();
    entry->GetKey()->SendStartDelayedAutoplayMediaComponents(this);
  }
}

IPCResult ContentChild::RecvStartDelayedAutoplayMediaComponents(
    BrowsingContext* aContext) {
  // Here I imagine BrowsingContext::StartDelayedAutoplayMediaComponents
  // recursively traverses the bc sub-tree starting at aContext and does it's
  // stuff.

  aContext->StartDelayedAutoplayMediaComponents();
  return IPC_OK();
}

Comment 6

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/f884c612401e
part1 : implement the way to resume delayed autoplay media via browsing context. r=farre
https://hg.mozilla.org/integration/autoland/rev/94f8d2ce7f8c
part2 : use browsing context to resume delayed autoplay media. r=farre
https://hg.mozilla.org/integration/autoland/rev/bc864bb5cd2b
part3 : remove unused message. r=baku

Comment 7

[Oana Pop-Rus]

https://hg.mozilla.org/mozilla-central/rev/f884c612401e
https://hg.mozilla.org/mozilla-central/rev/94f8d2ce7f8c
https://hg.mozilla.org/mozilla-central/rev/bc864bb5cd2b

Comment 8

[Maria Berlinger [:mberlinger], Services QA]

Alastor, is there anything manual QA can do to help test this?

Comment 9

[Alastor Wu [:alwu]]

It can be simply tested by checkin whether sound indicator can mute/unmute audio from tab.

Comment 10

[Alastor Wu [:alwu]]

Ah, sorry, I just realized that this bug is not about muting/unmuting audio in the tab (bug1553328). The way to verify is to check whether play tab icon is work.

Comment 11

[Maria Berlinger [:mberlinger], Services QA]

Marking as qe+ based on the above mentions.

Comment 12

[Vlad Lucaci, Thunderbird QA (:vlucaci)]

Confirming this issue as verified fixed on Nightly 70.0a1 (2019-07-16) and Nightly 69.0a1(2019-07-04) on Windows 10x64 , macOS 10.14 and Ubuntu 18.04x64. The Play tab icon is working as expected.