Bug 173268 - [MediaStream iOS] If a capturing tab is muted while it is in the background, it can not be unmuted
Summary: [MediaStream iOS] If a capturing tab is muted while it is in the background, ...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebRTC (show other bugs)
Version: Other
Hardware: Unspecified Unspecified
: P2 Normal
Assignee: Eric Carlson
URL:
Keywords: InRadar
Depends on:
Blocks:
 
Reported: 2017-06-12 11:16 PDT by Eric Carlson
Modified: 2019-06-04 20:19 PDT (History)
9 users (show)

See Also:


Attachments
Proposed patch. (14.69 KB, patch)
2017-06-12 11:42 PDT, Eric Carlson
jer.noble: review+
buildbot: commit-queue-
Details | Formatted Diff | Diff
Archive of layout-test-results from ews104 for mac-elcapitan-wk2 (1.19 MB, application/zip)
2017-06-12 12:59 PDT, Build Bot
no flags Details
Updated patch. (14.79 KB, patch)
2017-06-12 13:27 PDT, Eric Carlson
no flags Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Carlson 2017-06-12 11:16:48 PDT
If a capturing tab is muted while it is in the background, it can not be unmuted
Comment 1 Eric Carlson 2017-06-12 11:17:17 PDT
<rdar://problem/32259809>
Comment 2 Eric Carlson 2017-06-12 11:42:39 PDT
Created attachment 312680 [details]
Proposed patch.
Comment 3 Build Bot 2017-06-12 12:59:28 PDT
Comment on attachment 312680 [details]
Proposed patch.

Attachment 312680 [details] did not pass mac-wk2-ews (mac-wk2):
Output: http://webkit-queues.webkit.org/results/3918657

New failing tests:
http/tests/media/media-stream/disconnected-frame.html
Comment 4 Build Bot 2017-06-12 12:59:30 PDT
Created attachment 312687 [details]
Archive of layout-test-results from ews104 for mac-elcapitan-wk2

The attached test failures were seen while running run-webkit-tests on the mac-wk2-ews.
Bot: ews104  Port: mac-elcapitan-wk2  Platform: Mac OS X 10.11.6
Comment 5 Eric Carlson 2017-06-12 13:27:27 PDT
Created attachment 312690 [details]
Updated patch.
Comment 6 WebKit Commit Bot 2017-06-12 14:56:59 PDT
Comment on attachment 312690 [details]
Updated patch.

Clearing flags on attachment: 312690

Committed r218140: <http://trac.webkit.org/changeset/218140>
Comment 7 Chris Dumez 2017-06-23 19:46:44 PDT
Comment on attachment 312690 [details]
Updated patch.

View in context: https://bugs.webkit.org/attachment.cgi?id=312690&action=review

> Source/WebCore/page/MediaProducer.h:49
> +        HasInterruptedAudioCaptureDevice = 1 << 15,

Are we intentionally using the same value here....

> Source/WebCore/page/MediaProducer.h:50
> +        HasInterruptedVideoCaptureDevice = 1 << 15,

... and here?

This looks odd.
Comment 8 Szymon Witamborski 2019-05-22 17:38:38 PDT
Hi Eric & Chris,

It seems our users are experiencing this issue and we can reproduce it every time the audio is played in another app (like YouTube) during a WebRTC call in iOS Safari. The only remedy it seems is to close the tab and reopen the call in a new tab. Re-requesting `getUserMedia` seems to get an audio track that doesn't have `muted` set to `true` but there's no signal.

Tested on iOS 12.3 on iPhone XR

best regards,
Szymon Witamborski
Comment 9 Darin Adler 2019-06-02 22:11:48 PDT
I think that adding a comment to this bug that was fixed with a code change two years ago is probably not the best way to report a new problem, even if the symptom is similar or the same.
Comment 10 Szymon Witamborski 2019-06-04 19:48:20 PDT
Apologies, I assumed this is still being worked on since it was never marked as resolved. Didn't want to open a potential duplicate.

I can open a new bug if that's what you prefer.

best regards,
Szymon Witamborski
Comment 11 youenn fablet 2019-06-04 20:19:58 PDT
Hi Szymon,

I just tried it on a recent iOS build and cannot reproduced it.
Here is what I tried:
- load https://webrtc.github.io/samples/src/content/peerconnection/pc1/
- click start and call to have an on-going webrtc call
- load youtube.com in another tab and start a video. At that point, the capture should be suspended
- go back to the previous tab, the capture should restart (and youtube be suspended).
Is it what you have tested?
If it is, it might be good if you could test it on an iOS 13 beta.
If it is not, please file a new bug, ideally with precise repro steps.