+++ This bug was initially created as a clone of Bug #926522 +++ A lighter weight test is 1. Load http://dev.noteflight.com/scores/view/66d71f5197498141dc00d01fffed1d383795fa61?app=html5 2. Click "Listen". 3. Wait for playing to start. 4. Quit. Expected results: shutdown quickly Actual results: shutdown takes longer than 30 seconds. What I think is the best solution is in bug 926522 and bug 928222, but those are fairly complex changes. The purpose of this bug is merely to undo the regression from http://hg.mozilla.org/mozilla-central/rev/8edc48525bc6 with a changeset that is suitable for branch uplift.

This happens to work because the window is closed before nsThreadManager is shutdown. It also doesn't prevent the same bug happening if a decode task is run after the window is closed, but solves the bug in the same cases as before 8edc48525bc6 landed. The destructor would be nice place to put this, but that doesn't run until after nsThreadManager shutdown.

Comment on attachment 829021 [details] [diff] [review] prevent MediaBufferDecoder threads from waiting after AudioContext shutdown Review of attachment 829021 [details] [diff] [review]: ----------------------------------------------------------------- ::: content/media/webaudio/MediaBufferDecoder.cpp @@ +542,5 @@ > +void > +MediaBufferDecoder::Shutdown() { > + if (mThreadPool) { > + // Setting threadLimit to 0 causes threads to exit when all events have > + // been run, like nsIThreadPool.shutdown(), but doesn't run a nested event Nit: nsIThreadPool::Shutdown().

Comment on attachment 829021 [details] [diff] [review] prevent MediaBufferDecoder threads from waiting after AudioContext shutdown [Approval Request Comment] Bug caused by (feature/regressing bug #): regression from bug 914030 in the new Web Audio decodeAudioData() method. User impact if declined: slow shutdown sometimes Testing completed (on m-c, etc.): on m-c Risk to taking this patch (and alternatives if risky): the patch is small, intended for minimum risk, and risk is confined to web audio. String or IDL/UUID changes made by this patch: none.

Mozilla/5.0 (Windows NT 6.3; WOW64; rv:27.0) Gecko/20100101 Firefox/27.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:27.0) Gecko/20100101 Firefox/27.0 Mozilla/5.0 (X11; Linux i686; rv:27.0) Gecko/20100101 Firefox/27.0 Verified as fixed on latest Aurora 27.0a2 (buildID: 20131202004002) where shutdown takes about 2-3 seconds.

Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:28.0) Gecko/20100101 Firefox/28.0 Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 The link from comment 0 is no longer available for testing (Page not found). Is there any other link that I could test with? I've tested with the link from bug 926522 comment 0 and no 1 minute hangs encountered on latest Aurora 28.0a2 (Build ID: 20131212004008), the shutdown takes about 3 seconds.

> The link from comment 0 is no longer available for testing (Page not found). > Is there any other link that I could test with? http://www.noteflight.com/scores/view/73a0b4eaca6ab417c81b001c0b7c21412a3505b5?app=html5 is simliar, but heavier. Wait for the score editor to load and set up. Click "Listen". wait for 1 sound to load and quit.

Mozilla/5.0 (Windows NT 6.1; WOW64; rv:28.0) Gecko/20100101 Firefox/28.0 Mozilla/5.0 (X11; Linux x86_64; rv:28.0) Gecko/20100101 Firefox/28.0 Mozilla/5.0 (Macintosh; Intel Mac OS X 10.9; rv:28.0) Gecko/20100101 Firefox/28.0 Thank you for the URL. Reproduced with Nightly from 2013-11-03. Verified as fixed on latest Aurora 28.0a2 (Build ID: 20131212004008) with STR from comment 9.