Closed Bug 517114 Opened 15 years ago Closed 10 years ago

Tear off video controls

Categories

(Toolkit :: Video/Audio Controls, defect)

x86
macOS
defect
Not set
normal

Tracking

()

RESOLVED FIXED
mozilla35

People

(Reporter: faaborg, Assigned: theinternetftw)

Details

(Whiteboard: [STR in comment #13])

Attachments

(2 files)

This might be a dupe, but I was just able to tear off the video controls like they were an image.  Releasing the mouse button produced this error:

ASSERT: In the drop event, at least one mime-type should match our supported types
Stack Trace: 
0:_onDrop([object DragEvent])
1:ondrop([object DragEvent])
Really? I can't seem to reproduce on a trunk build. Any particular STR, or are you able to do it for any video?
The specific video I was getting this behavior on is here:

http://people.mozilla.com/~limi/videos/talks/ff-3.7-4.0-all-hands.ogg

I wasn't able to reproduce today, but yesterday I could reproduce repeatedly by dragging the scrub marker and pulling it off.
Attached image Bug in progress
Taken with an iPhone since there wasn't really any way to get a screen grab with the mouse depressed.
What version / buildid of Firefox are you seeing this with?
>What version / buildid of Firefox are you seeing this with?

namoroka nightly build from Wednesday
If it helps with the STR, I had been doing a whole lot of scrubbing in the video before I experienced this bug.
Just ran into this while testing seeking in a video.  It's much easier to reproduce when the controls are always visible, so I worked out simple steps to reproduce using a Vorbis-only file:

1. Load http://upload.wikimedia.org/wikipedia/commons/a/ab/Schubert_-_Piano_Sonatas_-_5_Moderato.ogg
2. Start a drag outside the controls in the empty page area, drag into the controls, then release.
3. Try to drag the controls.
Component: Video/Audio → Video/Audio Controls
Product: Core → Toolkit
QA Contact: video.audio → video.audio
Version: Trunk → unspecified
I can't reproduce this on Windows [Mozilla/5.0 (Windows NT 6.1; WOW64; rv:2.0b6) Gecko/20100101 Firefox/4.0b6], it might be Mac & Linux only.
Can't reproduce on today's nightly, on mac & linux.
Status: NEW → RESOLVED
Closed: 13 years ago
Resolution: --- → WORKSFORME
I can still reproduce this on Linux using the steps in comment 7.
Status: RESOLVED → REOPENED
Resolution: WORKSFORME → ---
I tried this on linux using steps in comment 7 and cannot reproduce.  Can anyone confirm?
I can reproduce it, occasionally, using comment 7 on OS X with a current Nightly. I'm not sure exactly what I'm doing to trigger it, but maybe 10% of my varied attempts to do so resulted in dragging an image of the controls.

Curiously, the drag image does not have any text (timestamp) in the scrubber thumb.
I just got 100% reproduction on Linux and Windows. The steps may surprise you.

Steps:
1) Load http://upload.wikimedia.org/wikipedia/commons/a/ab/Schubert_-_Piano_Sonatas_-_5_Moderato.ogg
2) Double click outside the controls (on the empty page)
3) Drag the controls

More Information:

* These steps seem to work with any video or audio element, e.g. the videos on http://www.quirksmode.org/html5/tests/video.html  Just double-click in the empty space to the left of a video, then try to drag that video (not just the controls, anywhere in the element).

* Notice that if you have two videos in view on the above quirksmode page, double-clicking to the left of one only lets you drag the video that is directly adjacent to your click, not the other. Thus the selection and drag events that are taking place look to be exactly the same as when you double-click next to an image element.

* If there are no controls on a video, you cannot drag it.
This fixes the drag behavior via preventDefault.

If you look at [1], it says all XUL is draggable by default and that the tearoff image is created automatically.  If that means it's on the XUL/XBL to prevent this behavior, then I'm pretty sure this is the way to do it.

Also, some commentary / a bit of a braindump:

The fact that video/audio elements can even be part of a selection should also be thought about. For instance, canvas can't be selected, but video can.  You can check all of this through this one liner:

document.getSelection().containsNode(document.getElementsByTagName('video' /*or canvas or audio*/)[0], true)

Try that with a video or audio element and it'll be true after the double click trick.  Try it on a canvas and it'll be false. On Chrome, it's false for both video and canvas.

All of the above also works with Ctrl-A, not just double clicking.  Which makes perfect sense.  However no amount of dragging or attempted lassoing will let you select a video element (except in IE).

(Another aside while I'm thinking about it: empty divs. <div style="width:500px;height:500px;background-color:red"/> will produce the same results (double-click outside + attempted drag). Chrome does select empty divs, but it doesn't let you drag them)

Anyway, I figured I'd go ahead and submit the simple patch anyway, because selection is hard and "should we drag" / "should we select" sound like two different questions, with the second needing a different bug report entirely.

[1] https://developer.mozilla.org/en-US/docs/Web/Guide/HTML/Drag_operations
Attachment #8498653 - Flags: review?(dolske)
Hmm. Trying to understand what's happening here.

The patch works, but I was wary that it could break dragging selections that happened to include a <video>. But it doesn't -- at least not with https://people.mozilla.org/~dolske/tmp/r.html: you can select-all the page, and starting to drag any of the leading/training text works fine while seeking in the video now works as expected (i.e. it doesn't drag). I guess we only fire dragstart at the element in the selection the user starts dragging? Makes sense, I suppose. 

I think a slightly more elegant way to control this is with CSS and "-moz-user-select: none".

That works, but not quite as narrowly-scoped as I'd have hoped... Setting it in videocontrols.css on .controlBar or even .mediaControlsFrame has no effect, nor did setting it on "video > xul|videocontrols" in layout/style/html.css. Setting it there as "video[controls] { -moz-user-select: none }" works, yay for big hammers I guess.

I'm guessing the relevant -moz-user-select code doesn't know how to deal with anonymous content (native anonymous content?).

I was mostly thinking it would be nice to have dragging videos working, just as you can drag a image to your desktop to save it. But at least on OS X, that seems to be broken already -- I just get a 0-byte "Untitled clipping.textClipping" file as a result. Looks like <canvas> has had selection disabled the same way for a long time, so probably not a big deal in practice.

So, let's just disable this with CSS in html.css? Not sure if it's worth followup bugs to allow disabling it only on the control bar and to make dragging a video to the desktop do something sensible.

roc -- have an opinion on that? I suppose you get to review it as a html.css change. :)
Status: REOPENED → NEW
Flags: needinfo?(roc)
Ben: when I said I was looking forward to your next patch, I had no idea what rabbit hole this would take us down! :) But it was a fun investigation!
I prefer Ben's patch to changing -moz-user-select here.
Flags: needinfo?(roc)
Comment on attachment 8498653 [details] [diff] [review]
patch1 - prevent default "tear-off" drag behavior

Review of attachment 8498653 [details] [diff] [review]:
-----------------------------------------------------------------

In that case, lgtm.
Attachment #8498653 - Flags: review?(dolske) → review+
https://hg.mozilla.org/mozilla-central/rev/8c0ced0c0ab1
Status: NEW → RESOLVED
Closed: 13 years ago10 years ago
Resolution: --- → FIXED
Target Milestone: --- → mozilla35
QA Whiteboard: [good first verify]
Whiteboard: [STR in comment #13]
You need to log in before you can comment on or make changes to this bug.