STR: 1. Visit https://soundcloud.com/kapslap/summer-mix-2015 (This should start playing audio.) 2. Open a private browsing window (Ctrl shift p) 3. Close the private browsing window (Ctrl w) 4. Wait 1 second. ACTUAL RESULTS: Soundcloud completely breaks, in my normal window. - Audio stops. - Soundcloud's big orange "pause" button turns into a "...". - If I click that button to try to get back into a playing state, nothing actually starts playing. - The only way to get music to play again seems to be by reloading. EXPECTED RESULTS: Soundcloud should keep working fine in my normal Firefox window.

I'm tracking this down with mozregression right now. In older builds (e.g. 2015-04-07), I get a ~1-second pause/blip in audio when I perform the STR, but then the audio resumes. That seems odd, but for the purposes of this bug, I'm considering that "working".

Regression range: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=eaf4f9b45117&tochange=c26dbd63604d Strongly suspecting csets for bug 1173467 "Cache API should at least reject in private browsing mode"

Note: in broken builds, I find that the STR occasionally gives EXPECTED RESULTS (with a short pause/blip) the first time, but give ACTUAL RESULTS (indefinite pause/breakage) if I repeat steps 2 & 3 -- i.e. if I open & close another PB window. So, this bug reproduces *pretty* reliably, but not quite 100%.

(In reply to Daniel Holbert [:dholbert] from comment #2) > Strongly suspecting csets for bug 1173467 "Cache API should at least reject > in private browsing mode" I'm wrong! mozregression over inbound builds produced this range... https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=28e6664ad1a1&tochange=9fb9dbd7a0dd ...which includes some media buffering related changes from bholley (mostly bug 1175768). Seems reasonable that a media-code change could've caused this. --> Adjusting component to Audio/Video.

302 jya. Sorry there've been so many of these Jean-Yves. Hopefully they're all related...

Can't reproduce in Beta 41.0b1 on Windows 8 (VM) nor Developer Edition as of 41.0a2 (2015-08-10) on mac. Can't reproduce in Nightly 42.0a1 (2015-08-10), nor Nightly 43.0a1 (2015-08-12) Daniel, on which version did you reproduce this ? Because that's WFM so far

I had e10s off in all those versions ; but turned it on in latest nightly, and still same problem

I was using latest nightly on Ubuntu 15.04. Hit the bug with e10s enabled & disabled (didn't matter).

I'm reproducing this right now, with latest Nightly 43.0a1 (2015-08-13) in a fresh profile (still Linux 15.04) Will try Windows as well to see if it's platform-specific.

Yeah, Windows Nightly doesn't seem to be affected -- I get behavior like comment 1 (short pause) when closing a PB window there. So this seems like it may be Linux-only. jya, did you happen to try this on Linux yet? (and do you have the ability to test on Linux?)

How linux!! That's very different then. totally different code path than windows or mac. Do you have gstreamer installed. Which gstreamer plugins do you have installed? Did you build it with ffmpeg enabled ? I'm hoping today's nightly with bug 1190238 in would fix your problem...

(In reply to Jean-Yves Avenard [:jya] from comment #11) > Do you have gstreamer installed. Which gstreamer plugins do you have > installed? Yes. I have gstreamer0.10-plugins-[bad, bad-multiverse, base, base-apps, good, ugly] installed. > Did you build it with ffmpeg enabled ? This is Nightly, so I didn't build it. But about:buildconfig doesn't have any mention of ffmpeg (or gstreamer). (IIRC, that's one difference between our Nightlies and the Ubuntu-provided Firefox package: the package from Ubuntu has "--enable-gstreamer=1.0" in about:buildconfig, and as a result uses e.g. native h.264 support. Our nightlies do not.)

So I reproduced the problem. with bug 1190238 applied; closing the window may sometimes pause the audio for about 1s or so but it restarts automatically . without bug 1190238; audio stops and can't be restarted. this is with gstreamer 1.0 and every single plugins I could find so not sure which one is in use. I think the pause is due to another bug I saw somewhere when if you close a private window it purges the media cache completely. If the cache is cleared, a pause in the audio is to be expected as it would need to rebuffer before audio can continue.

I think this bug can be marked as fixed, if you can verify it with tomorrow's nightly (or now with a nightly you build yourself)

That's great news! I'll retest tomorrow once the new nightly is out, & update the bug. Thanks!

Or you can end my misery (as really, I can't wait to know) and try http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64/1439508759/ fresh out of the oven

Was retesting with gstreamer 1.0 ; and I even got it to crash without bug 1190238

that was gstreamer 0.10

(In reply to Jean-Yves Avenard [:jya] from comment #16) > Or you can end my misery (as really, I can't wait to know) and try > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-central-linux64/1439508759/ Seems to work (can't reproduce the full stoppage -- just brief pauses per comment 1). --> Resolving as FIXED w/ dependency on bug 1190238

Hmm. When trying this out in today's nightly, I'm hitting a nearly-as-bad bug -- some fraction of the time, I get a into a state where it'll load with oscillating "..." icon for ~10 seconds, and then play two short blips of music (separated by about a second), then go back to "..." for 10 seconds, and then 2 more blips, and repeat. This isn't 100% reproducible, but it's happened twice within ~3-4 minutes of testing (with my other attempts all being fine). As in comment 0, the only reliable way to recover once I'm in this state seems to be to reload. (Seeking occasionally fixes it, but not always.) jya, should I reopen, or file a new bug?

(Just reproduced comment 20 a 3rd time, btw)

I can't reproduce anything like that.. I've seen where it pauses for a while, and you see the three dots going but then always resumed (and I've tried it again and again hundreds of times) I'm wondering if you're just not hitting a bug in gstreamer and that prior the first regression you would have hit it too. Just that it was never tested that much under that particular scenario.. The core issue is that the media cache appears to be flushed when closing any private window. What's the rationale behind that? Why aren't private windows using their own media cache instead.

What if you update to gstreamer 1.0; can you reproduce it?

(In reply to Jean-Yves Avenard [:jya] from comment #22) > The core issue is that the media cache appears to be flushed when closing > any private window. Yup, looks like it. > What's the rationale behind that? Why aren't private > windows using their own media cache instead. (Good question! Not sure who'd be the right person to ask about that. Maybe ehsan?) (In reply to Jean-Yves Avenard [:jya] from comment #23) > What if you update to gstreamer 1.0; can you reproduce it? Sorry, looks like I lied in comment 12 -- looks like I have both gstreamer 0.10 *and* 1.0 plugins installed. I'll attach my full list of gstreamer packages in a minute. (So, to answer your question -- yes, I can reproduce with gstreamer 1.0 installed. Though I suppose I can't be 100% sure whether the 1.0 vs. 0.1 versions are getting invoked here.)

Here are all of my installed packages with 'gstreamer' in their name, generated using this command: dpkg --get-selections | grep gstreamer | cut -f1

I'm having a harder time reproducing comment 20 now. (Tried both an old pre-regression build, 2015-04-27, as well as current nightly.) I just reproduced the original ACTUAL RESULTS (from comment 0), though, after ~5 minutes of trying with current Nightly. This is still kind of good news, because previously it was extremely easy to reproduce, and now it takes a lot of work to reproduce. So I think it's fine to still consider this bug FIXED, and I spun off bug 1194891 about why we're clearing the full media cache in the first place. (Presumably that would fix all the remaining weirdness described here.) Transferring my ni=ehsan to that bug.

With bug 1209410, there should be no noticeable effect that the media cache has been flushed

Yup, I can't repro with current nightly. No blips/interruptions when performing comment 0's STR. Thanks!

Closing a private browsing window in FF 48 still causes at least a drop-out a second or so later, up to ~5 seconds long. Reproduced with the following steps: * Fedora 24 * New Firefox profile * Open http://bbcmedia.ic.llnwd.net/stream/bbcmedia_radio1_mf_p (BBC Radio 1) in a normal window * Open a blank private browsing window * Close the private browsing window

(In reply to mozilla from comment #29) > Closing a private browsing window in FF 48 still causes at least a drop-out > a second or so later, up to ~5 seconds long. [...] > * Open http://bbcmedia.ic.llnwd.net/stream/bbcmedia_radio1_mf_p Thanks for the report! I can reproduce that as well, on Ubuntu (with that URL, though the original SoundCloud URL here is still fine). Could you file a new bug to cover your issue? (I think it's an independent issue from what was fixed here, though the symptoms are similar -- and from a tracking perspective, it's cleanest to avoid reopening bugs that have been closed, particularly when the originally-reported issue [at SoundCloud in this case] is indeed fixed.)

Didn't see the related open bug, #1194891. I'll add to that.