[Webkit-unassigned] [Bug 55198] LayoutTests/http/tests/media/video-play-suspend is now hanging on chromium
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Thu Feb 24 21:11:23 PST 2011
https://bugs.webkit.org/show_bug.cgi?id=55198
--- Comment #1 from Eric Carlson <eric.carlson at apple.com> 2011-02-24 21:11:23 PST ---
(In reply to comment #0)
> This just started hanging for chrome due to a cl of mine (http://codereview.chromium.org/6581012/) which causes the MediaPlayer states to transition from 'loading -> loaded ->idle' instead of 'loading -> idle'. This appears to be the correct spec thing to do as a progress event is now fired when the media has completed loading (which it wasn't before), but a side effect is that the 'suspend' event is now not being fired as the network doesn't actually suspend (indicated by a 'loading -> idle' transition).
>
> I ran the test under safari and the test also hangs there too.
>
> So it seems to me that the test is actually not testing for correct behaviour.
>
> Thoughts?
'suspend' is to be fired when the UA stops downloading for some reason:
When a media element's download has been suspended, the user agent must set the
networkState to NETWORK_IDLE and queue a task to fire a simple event named suspend
at the element.
so HTMLMediaElement fires it when the media engine signals a network state change from 'loading' or 'loaded' to MediaPlayer::Idle.
I think the problem is in HTMLMediaElement::setNetworkState, where MediaPlayer::Loaded results in m_networkState being set to NETWORK_IDLE without firing a 'suspended' event. I think it should fire a 'suspend' event just before the final 'progress' event, though we will have to see if it causes other problems.
--
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
More information about the webkit-unassigned
mailing list