- From: <bugzilla@jessica.w3.org>
- Date: Wed, 02 Mar 2011 23:49:48 +0000
- To: public-html-bugzilla@w3.org
http://www.w3.org/Bugs/Public/show_bug.cgi?id=12227 Summary: The readyState check in the "potentially playing" definition should not be used to influence GC of media elements Product: HTML WG Version: unspecified Platform: All OS/Version: All Status: NEW Severity: normal Priority: P3 Component: HTML5 spec (editor: Ian Hickson) AssignedTo: ian@hixie.ch ReportedBy: adrianba@microsoft.com QAContact: public-html-bugzilla@w3.org CC: mike@w3.org, public-html-wg-issue-tracking@w3.org, public-html@w3.org See the thread starting at [1] including [2] and [3]. We've analysed this section of the spec. http://dev.w3.org/html5/spec/video.html#media-playback This uses the phrase "potentially playing", which is defined as: "A media element is said to be potentially playing when its paused attribute is false, the readyState attribute is either HAVE_FUTURE_DATA or HAVE_ENOUGH_DATA, the element has not ended playback, playback has not stopped due to errors, and the element has not paused for user interaction." http://dev.w3.org/html5/spec/video.html#potentially-playing The problem with this is that there is still a race between the GC and the network in this example: function playAudio() { var a = new Audio("http://www.example.com/music"); a.play(); } This means that after the function exits, the behaviour will vary depending upon whether the GC fires before or after readyState gets to HAVE_FUTURE_DATA. We propose removing the readyState check from potentially playing this specific scenario so that the element will only be available to be collected on error, when paused, at the end of the media, or if somehow stopped by user interaction. [1] http://lists.w3.org/Archives/Public/public-html/2011Jan/0438.html [2] http://lists.w3.org/Archives/Public/public-html/2011Feb/0006.html [3] http://lists.w3.org/Archives/Public/public-html/2011Feb/0007.html -- Configure bugmail: http://www.w3.org/Bugs/Public/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are the QA contact for the bug.
Received on Wednesday, 2 March 2011 23:49:50 UTC