Actual Result: When the user selects to load the Bioshock video https://www.youtube.com/watch?v=hicBgE6XndM , puts the computer to sleep, and then selects to awake computer, and continue to watch the video; the video will enter an infinite loading state

I reproduced this on my Razerblade laptop running Windows 8.0 64-bit. * Firefox 36.0.4 - playback resumes from sleep * Firefox 37.0b7 - playback resumes from sleep * Firefox 38.0a2 - video is stuck in a loading state from sleep * Firefox 39.0a1 - [Tracking Requested - why for this release]: this is a regression.

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #2) > * Firefox 38.0a2 - video is stuck in a loading state from sleep > * Firefox 39.0a1 - Sorry, I meant to say here that Firefox 39.0a1 displays the same behaviour as Firefox 38.0a2.

Last Good: 2015-02-19 [986e840a2979] First Bad: 2015-02-20 [1b4c5daa7b7a] Pushlog: https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=986e840a2979&tochange=1b4c5daa7b7a

Tracking for 38 and 39. Anthony can you suggest someone to work on this? Thanks!

Ralph, can you help with this bug? Thanks

The most likely looking changes from the regression window are the cubeb and rendering changes, e.g. bug 1134078. Kinetik, does that seem plausible to you? Otherwise, ashughes, could you reproduce with logging enabled and attach? That will help track down where it's getting stuck. MEDIA_LOG_SAMPLES=1 NSPR_LOG_MODULES=MediaDecoder:5,MediaSource:5,MediaPromise:5,nsMediaElement:5,nsMediaElementEvents:5

Here is the log you requested, Ralph.

In a further development, after installing the latest Windows 8.1 updates I can no longer reproduce this bug. I'm doing a system restore right now to see if that makes this reproduce again. That said, if an updated Windows system cannot reproduce this then maybe the bug is moot.

(In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #10) > In a further development, after installing the latest Windows 8.1 updates I > can no longer reproduce this bug. I'm doing a system restore right now to > see if that makes this reproduce again. That said, if an updated Windows > system cannot reproduce this then maybe the bug is moot. Scratch that - the bug does not reproduce when I have NSPR logging enabled. Rolling back the updates the bug came back but once I turned NSPR logging on the bug disappeared.

Well I can't reproduce this bug in any build anymore on this system. In the course of trying to get the logging to work, this bug went away. If we need the logging to move forward on this I'll need to escalate this to Betabreakers.

Here is the nspr log from my machine, even though it's not reproducing the bug anymore, just in case it's still useful.

For some reason the log got cut off, here it is again.

Ralph, can you please prepare a Try server build to test the theory that bug 1134078 might be the cause? I've received approval to have Todd do some more testing and debugging for us.

Todd, can you please help us debug this further: 1. Check to see if the bug still reproduces using the build you tested before 2. Check to see if the bug reproduces in the latest Firefox 38: https://beta.mozilla.org/ 3. Check to see if the bug reproduces in the latest Firefox Nightly: https://nightly.mozilla.org/ 4. Check to see if the bug reproduces in Ralph's Try server build (when available). 5. Install all Windows updates and check the above builds continue to reproduce the bug. If the bug still reproduces I will provide further instruction so you can generate logs for us. If the bug stops reproducing I will provide further instruction so you can narrow down the "fix" range for us.

It's possible/likely the audio thread hang prevention added in bug 1134078 (the timeout added to the WaitForMultipleObjects call) is being triggered by the sleep/wake transition. I've pushed a potential fix to Try for testing: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1b75e6903bed This change requires the wait to timeout multiple times in a row with no other activity before the hang prevention is triggered. The timeout should only trigger once across a sleep/wake cycle, so if my guess about the cause is correct, this should fix the problem.

Anthony, This still occurs when using the build that I tested before (FF 38.0a2 Build ID: 20150330004006)I'm in the process of gathering 'about' files, and testing the other versions as you mentioned (In reply to Anthony Hughes, QA Mentor (:ashughes) from comment #16) > Todd, can you please help us debug this further: > > 1. Check to see if the bug still reproduces using the build you tested before > 2. Check to see if the bug reproduces in the latest Firefox 38: > https://beta.mozilla.org/ > 3. Check to see if the bug reproduces in the latest Firefox Nightly: > https://nightly.mozilla.org/ > 4. Check to see if the bug reproduces in Ralph's Try server build (when > available). > 5. Install all Windows updates and check the above builds continue to > reproduce the bug. > > If the bug still reproduces I will provide further instruction so you can > generate logs for us. If the bug stops reproducing I will provide further > instruction so you can narrow down the "fix" range for us.

Reverting just the change from bug 1134078 wasn't straigtforward, so I did a build with the entire cubeb library reverted to the version we used prior to that bug landing. So there may be other issues from regression subsequent bugs. Nevertheless: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/rgiles@mozilla.com-1308000b1bbf/try-win32/ https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/rgiles@mozilla.com-1308000b1bbf/try-win32-debug/ Use the first one for basic reproduction. The second, debug build for generating logging.

And of course try Kinetik's build, https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mgregan@mozilla.com-1b75e6903bed/try-win32/firefox-40.0a1.en-US.win32.zip

Here are the testing results for 4/10/2015: I was still able to reproduce Bug 1144199: Bio shock Infinite video goes to infinite loading screen when resuming playing after putting computer to sleep This occurred on all versions of FF that were provided to me: - Firefox 38.0a2 (Build ID: 20150330004006) *Previous build tested - Firefox Beta 38.0 (Build ID: 20150406174117) - Firefox Nightly 40.0a1 (Build ID: 20150410030204) During testing I observed that when setting the video quality to 1080p, putting my system to sleep, and then awakening the system; the video would enter an indefinite load state. However if I changed the resolution to something lower than 1080p; the video would continue to play. This issue does NOT occur on the following build: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/rgiles@mozilla.com-1308000b1bbf/try-win32/firefox-40.0a1.en-US.win32.installer.exe I receive a 'Bad news first: This tab has crashed' error when returning to FF tab that has the Bio shock video from a sleep state' When trying to reproduce this issue with https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mgregan@mozilla.com-1b75e6903bed/try-win32/firefox-40.0a1.en-US.win32.installer.exe Machine name: JANDICE Operating System: Windows 8.1 64-bit (6.3, Build 9600) (9600.winblue_r8.150127-1500) Language: English (Regional Setting: English) System Manufacturer: Hewlett-Packard System Model: h8-1400z BIOS: v8.08 Processor: AMD FX(tm)-8120 Eight-Core Processor (8 CPUs), ~3.1GHz Memory: 8192MB RAM Available OS Memory: 7982MB RAM Page File: 1963MB used, 6417MB available

Todd, thank you for the results. Ralph, based on Todd's testing does this give any more evidence that bug 1134078 is the cause? Is there still benefit in having Todd generate some logs with a broken build? Kinetik, it seems like your Try build is actually worse off for Todd.

Hmm, the 1080p correlation doesn't sound like cubeb, but reverting to the cubeb version prior to bug 1134078 removing the issue does. Kinetik, I think it's more likely to be yours at this point. Can you take a look and unassign if you change your mind about the cause? Todd, I don't think logging is helpful to get at this point. Can you test Kinetik's build with e10s disabled though? There might be an interaction there causing the crash which I'd like to eliminate. Flip the pref by going to about:preferences, General, uncheck 'Enable E10S (multi-process)', and restart Firefox.

Ralph - I receive an 'Nightly has stopped working' dialogue box after disabling 'E105 (multi-process) (In reply to Ralph Giles (:rillian) from comment #23) > Hmm, the 1080p correlation doesn't sound like cubeb, but reverting to the > cubeb version prior to bug 1134078 removing the issue does. Kinetik, I think > it's more likely to be yours at this point. Can you take a look and unassign > if you change your mind about the cause? > > Todd, I don't think logging is helpful to get at this point. Can you test > Kinetik's build with e10s disabled though? There might be an interaction > there causing the crash which I'd like to eliminate. Flip the pref by going > to about:preferences, General, uncheck 'Enable E10S (multi-process)', and > restart Firefox.

There was a dumb bug in my potential fix: I accidentally moved the break inside the timeout counter condition, so it was falling through to the unhandled case and asserting -- sorry about wasting your time with that build. Fixed build should be available via this Try push soon: https://treeherder.mozilla.org/#/jobs?repo=try&revision=ce811fc687b7

Todd, would you mind retesting with the build in http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mgregan@mozilla.com-ce811fc687b7/try-win32/ please?

Testing in progress. Will give an update shortly (In reply to Matthew Gregan [:kinetik] from comment #26) > Todd, would you mind retesting with the build in > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mgregan@mozilla. > com-ce811fc687b7/try-win32/ please?

Matthew; This issue does NOT occur on the build that you provided > > (In reply to Matthew Gregan [:kinetik] from comment #26) > > Todd, would you mind retesting with the build in > > http://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/mgregan@mozilla. > > com-ce811fc687b7/try-win32/ please?

Thanks for testing the build and confirming that it solves the problem, Todd. I'll prepare a patch for review.

Try push: https://treeherder.mozilla.org/#/jobs?repo=try&revision=87b55f127adb

Comment on attachment 8592007 [details] [diff] [review] bug1144199_v0.patch Approval Request Comment [Feature/regressing bug #]: bug 1134078 [User impact if declined]: no audio and/or broken media playback after system sleep/hibernate [Describe test coverage new/current, TreeHerder]: manually tested [Risks and why]: low, extends existing timeout mechanism with a simple change [String/UUID change made/needed]: none

Comment on attachment 8592007 [details] [diff] [review] bug1144199_v0.patch I guess we want aurora & beta (not beta & release) Should be in 38 beta 5

Todd, one last thing - can you check the fixed builds when they come out? Firefox 40.0a1 should have the fix tomorrow (April 16) [https://nightly.mozilla.org] Firefox 39.0a2 should have the fix tomorrow (April 16) [https://aurora.mozilla.org] Firefox 38.0b5 should have the fix on Friday (April 17) [https://beta.mozilla.org]

(In reply to Sylvestre Ledru [:sylvestre] from comment #35) > I guess we want aurora & beta (not beta & release) Oops, yes, sorry - wrong flags!

Anthony, This issue does not occur when testing the following builds: Firefox 40.0a1 should have the fix tomorrow (April 16) [https://nightly.mozilla.org] Firefox 39.0a2 should have the fix tomorrow (April 16) [https://aurora.mozilla.org] I will test Firefox 38.0b5 tomorrow (when it comes in) (In reply to Anthony Hughes, QA Mentor (:ashughes) [Away April 16-26] from comment #38) > Todd, one last thing - can you check the fixed builds when they come out? > > Firefox 40.0a1 should have the fix tomorrow (April 16) > [https://nightly.mozilla.org] > Firefox 39.0a2 should have the fix tomorrow (April 16) > [https://aurora.mozilla.org] > Firefox 38.0b5 should have the fix on Friday (April 17) > [https://beta.mozilla.org]

Anthony, As of 4/17/2015: This bug still occurs on Firefox 38.0b5 [https://beta.mozilla.org] Application Basics ------------------ Name: Firefox Version: 38.0 Build ID: 20150413143743 Update Channel: beta User Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:38.0) Gecko/20100101 Firefox/38.0 Multiprocess Windows: 0/1 (default: false) Crash Reports for the Last 3 Days --------------------------------- All Crash Reports Extensions ---------- Graphics -------- Adapter Description: AMD Radeon HD 7670 Adapter Drivers: aticfx64 aticfx64 aticfx64 aticfx32 aticfx32 aticfx32 atiumd64 atidxx64 atidxx64 atiumdag atidxx32 atidxx32 atiumdva atiumd6a atitmm64 Adapter RAM: 1024 Device ID: 0x675b Direct2D Enabled: true DirectWrite Enabled: true (6.2.9200.16581) Driver Date: 2-19-2013 Driver Version: 9.12.2.3000 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Subsys ID: 6888103c Vendor ID: 0x1002 WebGL Renderer: Google Inc. -- ANGLE (AMD Radeon HD 7670 Direct3D11 vs_5_0 ps_5_0) windowLayerManagerRemote: true AzureCanvasBackend: direct2d 1.1 AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0 Important Modified Preferences ------------------------------ browser.cache.disk.capacity: 358400 browser.cache.disk.smart_size.first_run: false browser.cache.frecency_experiment: 4 browser.download.importedFromSqlite: true browser.places.smartBookmarksVersion: 7 browser.startup.homepage_override.buildID: 20150413143743 browser.startup.homepage_override.mstone: 38.0 dom.mozApps.used: true extensions.lastAppVersion: 38.0 media.gmp-eme-adobe.lastUpdate: 1429291015 media.gmp-eme-adobe.version: 8 media.gmp-gmpopenh264.lastUpdate: 1429291015 media.gmp-gmpopenh264.version: 1.3 media.gmp-manager.buildID: 20150413143743 media.gmp-manager.lastCheck: 1429291014 network.cookie.prefsMigrated: true network.predictor.cleaned-up: true places.history.expiration.transient_current_max_pages: 104858 plugin.disable_full_page_plugin_for_types: application/pdf privacy.sanitize.migrateFx3Prefs: true Important Locked Preferences ---------------------------- JavaScript ---------- Incremental GC: true Accessibility ------------- Activated: false Prevent Accessibility: 0 Library Versions ---------------- NSPR Expected minimum version: 4.10.8 Version in use: 4.10.8 NSS Expected minimum version: 3.18 Basic ECC Version in use: 3.18 Basic ECC NSSSMIME Expected minimum version: 3.18 Basic ECC Version in use: 3.18 Basic ECC NSSSSL Expected minimum version: 3.18 Basic ECC Version in use: 3.18 Basic ECC NSSUTIL Expected minimum version: 3.18 Version in use: 3.18 Experimental Features ---------------------

Build ID: 20150413143743 (it is a date) I am pretty sure it is beta 4 as we built beta 5 yesterday. We are going to push beta 5 in an hour max. Could you update and try then?

So as of 2:00pm (PST) a couple of things are happening when testing the build on URL here. When setting up a test environment with the following three videos (as seen on the FF 38 wiki) • https://www.youtube.com/watch?v=Jp59FElhOTw (set to 1080p) • https://www.youtube.com/watch?v=79ImZE0K7xc (set to 1080p) • https://www.youtube.com/watch?v=7SRTEXSpcyI (set to 1080p) Loading the Bio Shock video (URL used for this bug) in 1080p; the video will not load (displays infinite loading loop). (Bug 1144237 - During Test 3 (Stress test) multiple videos buffer forever or just stop playing https://bugzilla.mozilla.org/show_bug.cgi?id=1144237) If I close the initial three video links (as seen on the FF 38 wiki) the Bio shock video will properly play in the 1080p resolution. After awakening my system from sleep mode; the video will continue to play without any issues (In reply to Sylvestre Ledru [:sylvestre] from comment #42) > Build ID: 20150413143743 (it is a date) > I am pretty sure it is beta 4 as we built beta 5 yesterday. > We are going to push beta 5 in an hour max. Could you update and try then?