[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