My browser hung on shutdown, I attached a debugger and wound up with the attached stack. Looks like we leaked the video element, and then hung when the CC tried to reclaim it.

Should the other-thread shutdown be async?

No idea if I see the identical thing so I would just ask before filing a new bug. Running a current nightly build on OS X and open the same website in at least 2 tabs doesn't let the browser shut-down. Even after opening a new window every website cannot be loaded anymore. Steps: 1. Open the following page in two tabs: http://www.gerv.net/temp/streaming-video.html 2. Wait some secs before trying to shutdown Firefox => Firefox cannot be closed 3. Open a new window and try to load any website => Firefox hangs and doesn't load anything Shall I file this as a new bug or is it the same issue as described here? I have to note that I wasn't able to get a stack trace yet.

I think it's the same bug, or at least a general 'shutdown can hang' problem after playing videos. There are a couple of areas causing the hang. The first is deadlocks in the shutdown code. The decoder thread can block inside liboggplay and shutdown waits for that thread to complete - it never does so there is a hang. This is fixed by the patch in bug 449159, which redesigned that area of the code. The second is calling Shutdown from the destructor of the decoder object. Shutdown can result in events being posted to the main thread - this is disussed in bug 449159, comment 32: "Shutdown remains a problem, although we shouldn't fix it in this bug. Basically when the element is destroyed we have to change the decoder's state to SHUTDOWN, remove the element reference from the decoder and post an XPCOM event to shutdown the decoder later." I'll probably resolve that in a patch to this bug since it seems to relate to this bug according to the stacktrace. The recently landed bug 451457 shuts the threads down during DestroyContent which means that the destructor call is unlikely to result in a blocking shutdown call, so part of that problem is addressed by that too.

The changes to shutdown referred to in comment 3 were landed in bug 449159. Does this resolve this bug?

I don't have good STR here, so I'm not sure, but if you think that would fix this case, I'm ok with resolving it.

Sorry, not fixed. With my STR from comment 2 it's still reproducible with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.1b2pre) Gecko/20081029 Minefield/3.1b2pre The only thing you have to do is opening videos within at least two tabs. Chris, my comment in bug 454194 could be a side-effect of this. Videos are mostly not played when you have the same page open in different tabs. Closing Minefield afterwards results in a hang.

ok, thanks. I missed the 'two tab' reference in comment two.

With a trunk build, I did the steps in comment #2 with five tabs and was able to shut down no problem. Henrik, are you still seeing this?

No, not anymore. I tested with a recent trunk and 1.9.1 branch build on Vista and OS X. I think we can safely mark it as WFM. Has been fixed by a patch on another bug. But what I'm wondering about is that with the given URL each tab will sync the video to the first opened tab. Even when the videos get started after each other with 5s or more delay, they will be in sync when switching between the tabs heavily. Shall I file a new bug on that Chris?

Gerv's page is linking to a real-time streaming video. So yeah, they should absolutely be in sync. If you turn on three TVs you'd definitely expect them to be in sync and it would be a bug if they weren't :-).