1753603 - Background Update task creates Volume Mixer sliders but does not remove them

Status: RESOLVED FIXED

(Toolkit :: Application Update, defect, P3)

Description

[[e-mail]]

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:96.0) Gecko/20100101 Firefox/96.0

Steps to reproduce:

Firefox is still spamming the Windows Volume Mixer with sliders it never deletes.

It's been getting better recently but it still happens. Unfortunately they only get added when I'm not using my computer. So after a bit of inspiration I went looking for possible background activities...

There are two scheduled tasks for Firefox in Windows: Default Browser Agent, and Background Update. If I right-click Background Update in Task Scheduler and click Run, a new mixer slider is created. The status changes from Ready to Running. If I then End the task from the same menu the mixer slider is not removed.

For me this happens every time I run the task. It is 100% reproducible.

The Default Browser Agent doesn't have the same problem.

Actual results:

Running the Background Update creates a new volume mixer slider. It probably doesn't need to do this anyway, but if it does then it should definitely clean up when it exits.

Expected results:

The mixer slider should either disappear when the task ends, or not appear at all in the first place.

Comment 1

[BugBot [:suhaib / :marco/ :calixte]]

The Bugbug bot thinks this bug should belong to the 'Toolkit::Application Update' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Nick Rishel [:nrishel]]

Thank you for digging into the issue and for the report!

P3 papercut that should be addressed, S4 cosmetic in nature.

Comment 3

[Nick Alexander :nalexander [he/him]]

What a world we live in. I've done some digging, and it's possible that the changes over in Bug 1617283 will address this. Let's wait for that to reland and retest. If that's not enough, we'll have to disable this audio session stuff in background task mode separately.

Comment 4

[Nick Alexander :nalexander [he/him]]

(In reply to Nick Alexander :nalexander [he/him] from comment #3)

What a world we live in. I've done some digging, and it's possible that the changes over in Bug 1617283 will address this. Let's wait for that to reland and retest. If that's not enough, we'll have to disable this audio session stuff in background task mode separately.

Actually, we still need to disable this, I think. That would be making this call to StartAudioSession conditional.

Comment 5

[Shazib Summar [:ssummar]]

(In reply to Nick Alexander :nalexander [he/him] from comment #4)

(In reply to Nick Alexander :nalexander [he/him] from comment #3)

What a world we live in. I've done some digging, and it's possible that the changes over in Bug 1617283 will address this. Let's wait for that to reland and retest. If that's not enough, we'll have to disable this audio session stuff in background task mode separately.

Actually, we still need to disable this, I think. That would be making this call to StartAudioSession conditional.

Hi there. You're right, the patch for bug 1617283 doesn't fix this issue. I would like to work on this. Could you kindly give me some pointers as where to start? Specifically could you kindly elaborate on your last comment?

Comment 6

[Nick Alexander :nalexander [he/him]]

(In reply to Shazib Summar [:ssummar] from comment #5)

(In reply to Nick Alexander :nalexander [he/him] from comment #4)

(In reply to Nick Alexander :nalexander [he/him] from comment #3)

What a world we live in. I've done some digging, and it's possible that the changes over in Bug 1617283 will address this. Let's wait for that to reland and retest. If that's not enough, we'll have to disable this audio session stuff in background task mode separately.

Actually, we still need to disable this, I think. That would be making this call to StartAudioSession conditional.

Hi there. You're right, the patch for bug 1617283 doesn't fix this issue. I would like to work on this. Could you kindly give me some pointers as where to start? Specifically could you kindly elaborate on your last comment?

Sure. The first step will be to repro (which I can do locally, FYI).

This was easiest to witness by enabling the old Volume Mixer control (which I did following these instructions). Then, build a full (compiled) Firefox. Run mach run --backgroundtask success --attach-console. If you do that a few times, you should see new volume controls being added, just like the reporter says.

To address this, don't StartAudioSession when we're in a background task, using a check like this one. In addition, don't StopAudioSession, either.

Then verify that you don't get volume controls with your new changes.

Thanks!

Comment 8

[Nick Alexander :nalexander [he/him]]

Attachment: Bug 1753603 - Don't `{Start,Stop}AudioSession` in background tasks. r?mossop

The presenting issue is that each background task's audio session is
user-visible via various Windows UIs that display "volume controls" or
"volume mixers"; this avoids that.

Comment 9

[Nick Alexander :nalexander [he/him]]

Removing dependency on Bug 1617283, since I don't think that work would actually address this (and it seems to have stalled).

Comment 10

[Pulsebot]

Pushed by [e-mail]:
https://hg.mozilla.org/integration/autoland/rev/d2fca1eebcfa
Don't `{Start,Stop}AudioSession` in background tasks. r=mossop

Comment 11

[Cristian Tuns]

https://hg.mozilla.org/mozilla-central/rev/d2fca1eebcfa