[webkit-reviews] review granted: [Bug 45263] Add mediaPlayerPlaybackStateChanged to MediaPlayerClient : [Attachment 66635] Patch

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Tue Sep 7 08:21:49 PDT 2010


Eric Carlson <eric.carlson at apple.com> has granted Tor Arne Vestbø
<vestbo at webkit.org>'s request for review:
Bug 45263: Add mediaPlayerPlaybackStateChanged to MediaPlayerClient
https://bugs.webkit.org/show_bug.cgi?id=45263

Attachment 66635: Patch
https://bugs.webkit.org/attachment.cgi?id=66635&action=review

------- Additional Comments from Eric Carlson <eric.carlson at apple.com>
> +	   updatePlayState() is then refactored to take into account the
> +	   situation where the backend is already in the correct state but
> +	   WebCore is not, so that we update thee playback progress timer

Typo - "thee"

>  
> +void HTMLMediaElement::mediaPlayerPlaybackStateChanged(MediaPlayer*)
> +{
> +    beginProcessingMediaPlayerCallback();
> +    if (m_player) {
> +	   if (m_player->paused())
> +	       pauseInternal();
> +	   else
> +	       playInternal();
> +    }
> +    endProcessingMediaPlayerCallback();
> +}
> +

Might as well return early if m_player is NULL.


> +	       // Set rate before calling play in case the rate was set before
the media engine wasn't setup.

Old typo you might as well fix, "wasn't" should be "was".


> Tried to keep the logic of updatePlayState() in the refactor, but wondering
about if (playerPaused && 
> couldPlayIfEnoughData()), should this check be moved out of the
play/not-playing block? Or perhaps be 
> done like this?
>
> if (!playerPaused)
>     m_player->pause();
>
> if (couldPlayIfEnoughData())
>     m_player->prepareToPlay();

Good idea, this seems much clearer.

Thanks!

r=me


More information about the webkit-reviews mailing list