Closed Bug 1524065 Opened 1 year ago Closed 1 year ago

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

Categories

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

enhancement

Tracking

()

VERIFIED FIXED
mozilla68
Fission Milestone M2
Tracking Status
firefox68 --- fixed
firefox69 --- verified
firefox70 --- verified

People

(Reporter: alwu, Assigned: alwu)

References

(Blocks 1 open bug)

Details

Attachments

(3 files)

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.

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.

Replace the current way and use the new way.

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

Priority: -- → P2

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

Flags: needinfo?(afarre)

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();
}

Flags: needinfo?(afarre)
Blocks: 1531114
Depends on: 1530550
Fission Milestone: --- → M2
Pushed by alwu@mozilla.com:
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
Status: NEW → RESOLVED
Closed: 1 year ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

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

Flags: qe-verify?
Flags: needinfo?(alwu)

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

Flags: needinfo?(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.

Marking as qe+ based on the above mentions.

Flags: qe-verify? → qe-verify+

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.

Flags: qe-verify+
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.