Re: [whatwg] A slightly different use-case for shared workers
Robert O'Callahan: Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Why shouldn’t that throw a WRONG_DOCUMENT_ERR? -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] A slightly different use-case for shared workers
On Fri, 29 Aug 2008 16:20:21 +0200, Cameron McCormack [EMAIL PROTECTED] wrote: Robert O'Callahan: Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Why shouldn’t that throw a WRONG_DOCUMENT_ERR? Because browsers knowingly violate the DOM and we now plan on updating the DOM specification to match the arguably more sane behavior of not throwing (and simply modifying ownerDocument). -- Anne van Kesteren http://annevankesteren.nl/ http://www.opera.com/
Re: [whatwg] A slightly different use-case for shared workers
I'm also a Pandora fan, and I actually thought of another use. In addition to popping out a separate player, Pandora also opens new tabs/windows to browse pages about artists/songs. These pages allow you to listen to samples, but listening to them does not pause the player. It would be pretty cool to use a shared worker to be able to tell the main player to pause if another window plays a sample and then resume when the sample completes. I don't know if this example actually contributes to the discussion, but it seemed like a cool idea :) On Fri, Aug 29, 2008 at 10:20 AM, Cameron McCormack [EMAIL PROTECTED] wrote: Robert O'Callahan: Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Why shouldn't that throw a WRONG_DOCUMENT_ERR? -- Cameron McCormack ≝ http://mcc.id.au/
Re: [whatwg] A slightly different use-case for shared workers
Anne van Kesteren wrote: On Fri, 29 Aug 2008 16:20:21 +0200, Cameron McCormack [EMAIL PROTECTED] wrote: Robert O'Callahan: Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Why shouldn’t that throw a WRONG_DOCUMENT_ERR? Because browsers knowingly violate the DOM and we now plan on updating the DOM specification to match the arguably more sane behavior of not throwing (and simply modifying ownerDocument). And even if we didn't do that a simple call to adoptNode will prevent WRONG_DOCUMENT_ERR from being thrown. / Jonas
Re: [whatwg] A slightly different use-case for shared workers
Aaron Boodman wrote: I encounter sites frequently that want to pop out part of their application free of the page, into a smaller window. For example, Pandora radio (http://pandora.com) does this. The player starts out embedded in the normal content area, but users have the option to pop it out into a smaller, separate window. One problem with these apps is that they have to shutdown and restart in the popup window. So if I'm playing a song in Pandora, it loses tracks of where I am and restarts in the pop out player. It seems like shared workers could help with this problem. If some future version of workers had access to the Audio API, the base pandora.com page would start a shared worker, which would be used to play the audio. If the user opted to open the player in a popup, the popup would simply obtain a reference to the existing worker. The music wouldn't have to restart. If the user navigated away from pandora.com, the popup would keep the worker alive until it was closed. I think that example could be solved simpler actually. An audio element can be moved between two documents without requiring any interference in its functionality. So if pandora used an audio to play music they could easily transfer the playing to another window. Ideally this would also work with plugins, However for various reasons this is very hard without modifying NPAPI. / Jonas
Re: [whatwg] A slightly different use-case for shared workers
On Thu, Aug 28, 2008 at 3:11 PM, Jonas Sicking [EMAIL PROTECTED] wrote: I think that example could be solved simpler actually. An audio element can be moved between two documents without requiring any interference in its functionality. So if pandora used an audio to play music they could easily transfer the playing to another window. Yup, Roc already schooled me. - a
[whatwg] A slightly different use-case for shared workers
I encounter sites frequently that want to pop out part of their application free of the page, into a smaller window. For example, Pandora radio (http://pandora.com) does this. The player starts out embedded in the normal content area, but users have the option to pop it out into a smaller, separate window. One problem with these apps is that they have to shutdown and restart in the popup window. So if I'm playing a song in Pandora, it loses tracks of where I am and restarts in the pop out player. It seems like shared workers could help with this problem. If some future version of workers had access to the Audio API, the base pandora.com page would start a shared worker, which would be used to play the audio. If the user opted to open the player in a popup, the popup would simply obtain a reference to the existing worker. The music wouldn't have to restart. If the user navigated away from pandora.com, the popup would keep the worker alive until it was closed. - a
Re: [whatwg] A slightly different use-case for shared workers
On Thu, Aug 28, 2008 at 9:59 AM, Aaron Boodman [EMAIL PROTECTED] wrote: I encounter sites frequently that want to pop out part of their application free of the page, into a smaller window. For example, Pandora radio (http://pandora.com) does this. The player starts out embedded in the normal content area, but users have the option to pop it out into a smaller, separate window. One problem with these apps is that they have to shutdown and restart in the popup window. So if I'm playing a song in Pandora, it loses tracks of where I am and restarts in the pop out player. It seems like shared workers could help with this problem. If some future version of workers had access to the Audio API, the base pandora.com page would start a shared worker, which would be used to play the audio. If the user opted to open the player in a popup, the popup would simply obtain a reference to the existing worker. The music wouldn't have to restart. If the user navigated away from pandora.com, the popup would keep the worker alive until it was closed. Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
Re: [whatwg] A slightly different use-case for shared workers
On Wed, Aug 27, 2008 at 5:23 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: On Thu, Aug 28, 2008 at 9:59 AM, Aaron Boodman [EMAIL PROTECTED] wrote: I encounter sites frequently that want to pop out part of their application free of the page, into a smaller window. For example, Pandora radio (http://pandora.com) does this. The player starts out embedded in the normal content area, but users have the option to pop it out into a smaller, separate window. One problem with these apps is that they have to shutdown and restart in the popup window. So if I'm playing a song in Pandora, it loses tracks of where I am and restarts in the pop out player. It seems like shared workers could help with this problem. If some future version of workers had access to the Audio API, the base pandora.com page would start a shared worker, which would be used to play the audio. If the user opted to open the player in a popup, the popup would simply obtain a reference to the existing worker. The music wouldn't have to restart. If the user navigated away from pandora.com, the popup would keep the worker alive until it was closed. Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Hm, that is a good point. I didn't consider the the audio object would keep playing smoothly when moved between documents. That seems unlikely to be reliable across implementations, but I'll keep my fingers crossed :). - a
Re: [whatwg] A slightly different use-case for shared workers
On Wed, 27 Aug 2008, Aaron Boodman wrote: Why not just open new window and move the playing audio element from the old window into the new window? You might need to call play() on it again in the new window, but you shouldn't lose your place in the stream. Hm, that is a good point. I didn't consider the the audio object would keep playing smoothly when moved between documents. That seems unlikely to be reliable across implementations, but I'll keep my fingers crossed :). We can create a test that keeps switching an audio element from one document to another 250 times a second and check that it plays smoothly the whole time. That seems like a good thing to have in our test suite. :-) -- Ian Hickson U+1047E)\._.,--,'``.fL http://ln.hixie.ch/ U+263A/, _.. \ _\ ;`._ ,. Things that are impossible just take longer. `._.-(,_..'--(,_..'`-.;.'
Re: [whatwg] A slightly different use-case for shared workers
On Thu, Aug 28, 2008 at 12:30 PM, Aaron Boodman [EMAIL PROTECTED] wrote: Hm, that is a good point. I didn't consider the the audio object would keep playing smoothly when moved between documents. That seems unlikely to be reliable across implementations, but I'll keep my fingers crossed :). Works on Firefox trunk :-). Testcase attached. (The Vorbis file takes a while to download so you should probably let it play through once before trying the test.) I have to confess I'm not completely unsurprised :-). Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6] Start playing Move to new window
Re: [whatwg] A slightly different use-case for shared workers
On Wed, Aug 27, 2008 at 6:46 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: Works on Firefox trunk :-). Testcase attached. (The Vorbis file takes a while to download so you should probably let it play through once before trying the test.) What is the rationale behind having to call play() again? Also, should it also work if you just pass a reference to the node into the other window? - a
Re: [whatwg] A slightly different use-case for shared workers
On Thu, Aug 28, 2008 at 2:23 PM, Aaron Boodman [EMAIL PROTECTED] wrote: On Wed, Aug 27, 2008 at 6:46 PM, Robert O'Callahan [EMAIL PROTECTED] wrote: Works on Firefox trunk :-). Testcase attached. (The Vorbis file takes a while to download so you should probably let it play through once before trying the test.) What is the rationale behind having to call play() again? I think the motivation was that if you remove a DOM subtree which happens to contain video or audio elements, they should pause. Otherwise, if you want to safely remove a DOM subtree you would have to always iterate through it to stop all media elements, otherwise you're leaking because elements (especially looping ones) can play indefinitely even if there are no outstanding references to them. A paused media element can be freed if there are no outstanding references to it, since there is no way for it to ever start playing again. Also, should it also work if you just pass a reference to the node into the other window? No, because its ownerdocument would be the old document and when that document is not active, the element will not play. Rob -- He was pierced for our transgressions, he was crushed for our iniquities; the punishment that brought us peace was upon him, and by his wounds we are healed. We all, like sheep, have gone astray, each of us has turned to his own way; and the LORD has laid on him the iniquity of us all. [Isaiah 53:5-6]
