Ignore MediaController in the muted/volume controls logic

Ignore MediaController in the muted/volume controls logic

Using MediaControllerInterface for volume/muted was a half-finished job,
since RenderMediaControls only considered HTMLMediaElement, so the
controls didn't really work with a media controller present.

The new test revealed a bug caused by MediaControls::changedVolume() not
considering the muted state. Consolidate the muted/volume handling to an
updateVolume() function to fix the bug and make the test pass.

The unconditional updateVolume() in reset() means that the volume will
always be set when the controls are first created. This revealed that
the media-volume-slider-hit-test test was broken: clickSliderMiddle() is
called when the volume slider isn't visible, and the clicked coordinates
are actually (0, 0). The test still passed because the default value for
a range input element is apparently the midpoint. Rewrite the test to
verify that clicking the volume slider actually updates the volume.

BUG=357236
TEST=LayoutTests/media/controls-mute-with-controller.html
     LayoutTests/media/controls-volume-slider.html

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=170414

[philipj_slow, 2014-03-28 16:59:45]

PTAL. Things were broken in the presence of a media controller and now they are
slightly less broken. What the user sees still may be different from what is
heard, but making sane controls when there are two sources contributing to the
state doesn't seem worth the effort, at least not until it becomes a real-world
problem.

[acolwell GONE FROM CHROMIUM, 2014-03-29 00:52:46]

lgtm

[philipj_slow, 2014-03-29 07:33:44]

I had "The m_muteButton->renderer()->repaint() call is not needed because
MediaControlElement::setDisplayType() will also call it." in the description.

That was wrong, because MediaControlElement::setDisplayType has an early return
and the mute button depends on both the volume and mute state. Fortunately we
had a test for this!

It would be awesome if the renderer and controls actually used a same state,
this isn't the first bit of non-obvious behavior I've run into...

[philipj_slow, 2014-03-29 09:30:34]

The CQ bit was checked by philipj@opera.com

[commit-bot: I haz the power, 2014-03-29 09:30:37]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/philipj@opera.com/217103004/20001

[commit-bot: I haz the power, 2014-03-29 10:13:43]

Change committed as 170414