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

RESOLVED FIXED in Firefox 68

Status

()

enhancement
P2
normal
RESOLVED FIXED
5 months ago
6 days ago

People

(Reporter: alwu, Assigned: alwu)

Tracking

(Blocks 1 bug)

unspecified
mozilla68
Points:
---
Dependency tree / graph
Bug Flags:
qe-verify +

Firefox Tracking Flags

(Fission Milestone:M2, firefox68 fixed)

Details

Attachments

(3 attachments)

Assignee

Description

5 months ago

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.

Assignee

Comment 1

5 months ago

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.

Assignee

Comment 2

5 months ago

Replace the current way and use the new way.

Assignee

Comment 3

5 months ago

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

Priority: -- → P2
Assignee

Comment 4

5 months ago

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)
Assignee

Updated

4 months ago
Blocks: 1531114
Assignee

Updated

4 months ago
Depends on: 1530550

Updated

3 months ago
Fission Milestone: --- → M2

Comment 6

3 months ago
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

Comment 7

3 months ago
bugherder
Status: NEW → RESOLVED
Closed: 3 months ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla68

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

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

Comment 9

28 days ago

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

Flags: needinfo?(alwu)
Assignee

Comment 10

27 days ago

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+
You need to log in before you can comment on or make changes to this bug.