In HTMLMediaElement, the ProgressEventTimer is started too soon. It currently begins at the very start of resource loading; it should instead start after the metadata has been loaded and media player has started buffering data. By firing right away, the timer gives the impression that playback is stalled and buffering - when in fact it is simply taking a long time to load the initial resource (meta data, etc.) As a result UI elements are activated prematurely and events are passed to the player before playback is actually taking place. This patch corrects this problem in order to conform with spec here : http://dev.w3.org/html5/spec/Overview.html#dom-media-network_loading.
Created attachment 99500 [details] This fixes the timer to be fired after media resource is loaded.
Attachment 99500 [details] did not pass style-queue: Failed to run "['Tools/Scripts/check-webkit-style', '--diff-files', u'Source/WebCore/ChangeLog', u'Source/WebCor..." exit_code: 1 Source/WebCore/ChangeLog:1: ChangeLog entry has no bug number [changelog/bugnumber] [5] Total errors found: 1 in 2 files If any of these errors are false positives, please file a bug against check-webkit-style.
Created attachment 99502 [details] This fixes the timer to be fired after media resource is loaded. Change Log updated with Bug ID.
The spec doesn't seem to require that the "stalled" and "progress" events require readyState() to be at HAVE_METADATA, only that the network state is at NETWORK_LOADING. Can you clarify where in the spec you think this requirement lies?
(In reply to comment #4) > The spec doesn't seem to require that the "stalled" and "progress" events require readyState() to be at HAVE_METADATA, only that the network state is at NETWORK_LOADING. Can you clarify where in the spec you think this requirement lies? I agree. Data must be loaded to reach HAVE_METADATA, and spec clearly says that progress events must be fired while media data is loaded: > Every 350ms (±200ms) or for every byte received, whichever is least > frequent, queue a task to fire a simple event named progress at > the element. and that a stalled event is to be fired when data loading stalls: > The stall timeout is a user-agent defined length of time, which > should be about three seconds. When a media element that is > actively attempting to obtain media data has failed to receive > any data for a duration equal to the stall timeout, the user > agent must queue a task to fire a simple event named stalled > at the element. http://www.w3.org/TR/html5/the-iframe-element.html#concept-media-load-resource
The Qt port has been removed from WebKit, resolving this bug.