Remove dead code for dragging MediaControlPanelElement

Remove dead code for dragging MediaControlPanelElement

Because setCanBeDragged(true) is never called, all the rest of the
dragging code becomes unreachable. The feature as such looks useful, but
it would require fixing and above all testing to interact well with text
track rendering.

BUG=341813
TEST=LayoutTests/media/ still passes, i.e. there were none!

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

[adamk, 2014-03-14 23:42:55]

https://codereview.chromium.org/196533020/diff/20001/Source/core/html/shadow/...
File Source/core/html/shadow/MediaControlElements.cpp (left):

https://codereview.chromium.org/196533020/diff/20001/Source/core/html/shadow/...
Source/core/html/shadow/MediaControlElements.cpp:213: void
MediaControlPanelElement::defaultEventHandler(Event* event)
It's strange that we'd actually run this code...the setDefaultHandled() calls
below really have no effect?

[philipj_slow, 2014-03-15 03:02:36]

https://codereview.chromium.org/196533020/diff/20001/Source/core/html/shadow/...
File Source/core/html/shadow/MediaControlElements.cpp (left):

https://codereview.chromium.org/196533020/diff/20001/Source/core/html/shadow/...
Source/core/html/shadow/MediaControlElements.cpp:213: void
MediaControlPanelElement::defaultEventHandler(Event* event)
The defaultEventHandler implementations in this file and MediaControls.cpp are
really bewildering. Sometimes the base class is called first, sometimes last.
Sometimes there's an early return, so that nothing is done. Sometimes
setDefaultHandled() isn't called. In one case,
MediaControlVolumeSliderElement::defaultEventHandler(), the base class call is
in the middle of the early returns.

I could put this all in order if I knew what was the idiomatic way of doing
things, is there a complicated defaultEventHandler I could compare to that's
actually correct?

[adamk, 2014-03-17 16:00:52]

+tkent, who's always been able to answer my questions about handling of input
events in Blink.

[tkent, 2014-03-17 22:39:41]

I think ancestors of MediaControlPanelElement don't have default event handling
for mouse events. So removing event->setDefaultHandled() is ok.

[philipj_slow, 2014-03-18 04:27:24]

On 2014/03/17 22:39:41, tkent wrote:
> I think ancestors of MediaControlPanelElement don't have default event
handling
> for mouse events. So removing event->setDefaultHandled() is ok.

What should be done when the ancestors do have default handling for the event in
question, as in this case:

void MediaControlMuteButtonElement::defaultEventHandler(Event* event)
{
    if (event->type() == EventTypeNames::click) {
       
mediaControllerInterface().setMuted(!mediaControllerInterface().muted());
        event->setDefaultHandled();
    }

    HTMLInputElement::defaultEventHandler(event);
}

Should one just return after calling setDefaultHandled()? It certainly seems
like the sensible thing by looking at HTMLInputElement::defaultEventHandler, but
I'd like to confirm before making that change everywhere.

[tkent, 2014-03-18 06:56:37]

On 2014/03/18 04:27:24, philipj wrote:
> On 2014/03/17 22:39:41, tkent wrote:
> > I think ancestors of MediaControlPanelElement don't have default event
> handling
> > for mouse events. So removing event->setDefaultHandled() is ok.
> 
> What should be done when the ancestors do have default handling for the event
in
> question, as in this case:
> 
> void MediaControlMuteButtonElement::defaultEventHandler(Event* event)
> {
>     if (event->type() == EventTypeNames::click) {
>        
> mediaControllerInterface().setMuted(!mediaControllerInterface().muted());
>         event->setDefaultHandled();
>     }
> 
>     HTMLInputElement::defaultEventHandler(event);
> }
> 
> Should one just return after calling setDefaultHandled()? It certainly seems
> like the sensible thing by looking at HTMLInputElement::defaultEventHandler,
but
> I'd like to confirm before making that change everywhere.

Default event handling for click event dispatches DOMActivate event. If
MediaControlMuteButtonElement is not interested in DOMActivate event, we can
skip HTMLInputElement::defaultEventHandler(event).

[philipj_slow, 2014-03-19 17:30:37]

acolwell, can you PTAL? The setDefaultHandled() cleanup wouldn't be part of this
patch, so I'll pursue it separately, I think I know what I need to know now.

[acolwell GONE FROM CHROMIUM, 2014-03-19 19:51:57]

lgtm

[philipj_slow, 2014-03-20 00:34:24]

The CQ bit was checked by philipj@opera.com

[commit-bot: I haz the power, 2014-03-20 00:34:34]

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

[commit-bot: I haz the power, 2014-03-20 03:55:31]

Change committed as 169606