Found by chance while debugging my patches for bug 1320994. Caused by a patch for bug 1228564 which moved audioCapture state from inner windows to outer windows. Audiocapture used to work like so: `gUM({audio: { mediaSource: "audioCapture" }})` AudioChannelService::AudioChannelWindow (outer window) notified of audioCapture and set up to notify agents about changes New consumers notified of capture changes looks up actual state in their associated inner window, see [1] And now it's like this: `gUM({audio: { mediaSource: "audioCapture" }})` AudioChannelService::AudioChannelWindow (outer window) notified of audioCapture and stores the state itself, [2] New consumers notified of capture-state (`true`) regardless of inner window, see [3]. This all means that an audioCapture now automatically captures all iframes in the same tab, even if one of the iframes initiated the audioCapture. Luckily audioCapture is prefed off by default. [1] http://searchfox.org/mozilla-central/diff/f0d62419f07766a8e5b956591d0f70ffdad3d1b3/dom/html/HTMLMediaElement.cpp#4986 [2] http://searchfox.org/mozilla-central/diff/f0d62419f07766a8e5b956591d0f70ffdad3d1b3/dom/audiochannel/AudioChannelService.cpp#667 [3] http://searchfox.org/mozilla-central/diff/f0d62419f07766a8e5b956591d0f70ffdad3d1b3/dom/audiochannel/AudioChannelService.cpp#301

Alastor, could you take a look? You wrote the patches on bug 1228564. Please add :padenot to reviews.

(In reply to Andreas Pehrson [:pehrsons] (Telenor) from comment #0) > This all means that an audioCapture now automatically captures all iframes > in the same tab, even if one of the iframes initiated the audioCapture. > Luckily audioCapture is prefed off by default. roc pointed out to me that this is not what outer and inner windows mean. Both outer and inner are per document (so not across iframes), but on navigation the outer stays and the inner remains. With that, and MediaManager that should stop audioCapture in OnNavigation, this might not be a bug at all.