1381620 - Cannot change <input type=range> position on non-contenteditable element inside contenteditable div

Status: NEW

(Core :: DOM: Editor, defect, P3)

Description

[Thomas Frenzel]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:54.0) Gecko/20100101 Firefox/54.0
Build ID: 20170630112252

Steps to reproduce:

<div contenteditable="true">
	before
	<div contenteditable="false">
		<video src="test.mp4" width="480" controls="controls"></video>
	</div>
	after
</div>


Actual results:

The video playback can be startet and stopped, but it is not possible to change the video position by clicking the timeline of the video controls when the video element or its parent is set contenteditable="false" and an ancestor of an element with contenteditable="true".


Expected results:

It should be possible to change the video position by clicking the timeline of the video controls, regardless of contenteditable attributes. Interestingly player controls are working as expected, when the video element inside the non-contenteditable div is made contenteditable.

Comment 1

[Makoto Kato [:m_kato]]

Could you provide completed sample?

Although I test the following, I can use seek bar.

data:text/html,<div contenteditable="true"><span>ABC</span><video src="http://video.webmfiles.org/big-buck-bunny_trailer.webm" controls="controls"></video></div>

Comment 2

[Makoto Kato [:m_kato]]

And, I test on 54 and nightly 56.  Can you reproduce on Nightly 56?

Comment 3

[Thomas Frenzel]

In your example the seek bar stops working when you add the attribute contenteditable="false" to the video element or, like in my example, wrap the video element into an additional div element with contenteditable="false". 

This also happens in Nightly 56.0a1.
On my other computer I still had a copy of Firefox 52, in which the video controls looked slightly different and worked normally. After the update to 54 they stopped working. So this behaviour was likely introduced in Firefox 53 or Firefox 54. I can reproduce this on different Windows and Linux platforms.

For context: the webapp I'm developing uses this construct in a WYSIWYG editor with file upload features (in this case video). The user can click a button or type a keyboard shortcut to create a file upload/preview element at the current editor position. After a successful upload of a video file the preview element contains the dynamically created video element, but also shows some file metainfo provided by the server, that should not be contenteditable by itself. As a workaround I added code that adds contenteditable="true" only to the video element within the preview element, which makes the seek bar working again for some reason.

Comment 4

[Makoto Kato [:m_kato]]

regression by bug 1271765

Comment 5

[Liz Henry (:lizzard) (relman/hg->git project)]

Sounds like a corner case, not the way pages usually use video.

Comment 6

[Ray Lin[:ralin]]

The conversion from XUL to HTML in Bug 1271765 brought out this issue. We can spot the similar issue if we reduce the test case:
```
data:text/html,<div contenteditable="true"><span>ABC</span><div contenteditable="false"><input type="range"></div></div>
```
I think DOM should be the more proper place to have a fix, though I can not figure out why range input's behavior varies in nested wrapper with different contenteditable value inherited. And I'm sorry I don't have cycles to looking into it right now, also I agree with Liz that this is not a common use. Nonetheless, I'll file a bug for range input and see if someone know the answer. Thanks.