Odd combination of video, track, and textarea elements leads to a crash
Reported by
adamjmci...@gmail.com,
Nov 2 2016
|
||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Windows NT 6.3; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/54.0.2840.71 Safari/537.36 Steps to reproduce the problem: 1. Check this fiddle: https://jsfiddle.net/_ajm/r717hqus/13/ 2. Attempt to select text in the textarea 3. The tab will crash What is the expected behavior? The user should be able to select textarea text. What went wrong? This is a reduced case based on something we noticed happening in a production app. In our app, we have a video and textarea appearing in an overlay. When users click in the textarea for any reason (to select text, just because they happened to), that tab will crash. I can fix the issue in the test case in any of the following ways: 1. Remove display: table from the outer containing div. (I've done this in our app as that container doesn't need that type of display set.) 2. Remove the track element entirely. 3. Remove the default attribute from the track element. 4. Set the display of the video element to inline-block. Doing any one of these things in the reduced test case in the fiddle will cause the issue not to appear. It seems like there's some weird interplay between display: table and the track element or the track element and event handling on the textarea, as odd as that sounds. Did this work before? N/A Does this work in other browsers? N/A Chrome version: 54.0.2840.71 Channel: n/a OS Version: 6.3 Flash Version: Shockwave Flash 23.0 r0 This certainly isn't a major issue by any means, but it seems very odd and the ways that I've found to resolve it seem even odder. I figured it was worth reporting.
,
Nov 4 2016
Can you provide a crash ID? https://www.chromium.org/for-testers/bug-reporting-guidelines/reporting-crash-bug
,
Nov 7 2016
In debug build, we hit DCHECK(!document.needsLayoutTreeUpdate()); during LayoutView::commitPendingSelection()
Due by font-size CSS property change in LayoutTextTrackContainer::layout()
Here is automated test case:
<style>
div{
background: rgba(0, 0, 0, 0.45);
height: 100%;
display: table;
position: fixed;
width: 100%;
}
video, textarea{
display: block;
height: 45%;
margin: 2.5% auto;
}
</style>
<div><video><track default></video><textarea>hello world
asdfasdf
</textarea></div>
<script>
document.querySelector('textarea').focus();
document.querySelector('textarea').setSelectionRange(0, 20);
</script>
,
Mar 14 2017
,
Mar 14 2017
I think this bug is different from bug 696561, though this is also a lifecycle violation. The fix method might be very different.
,
Mar 14 2017
,
Mar 15 2017
,
Mar 27 2017
It's not clear that this is a CSS (or layout) issue. Blink>Media folks, can you triage this please?
,
Apr 9 2017
+fs@ would removing LayoutTextTrackContainer solve this issue?
,
Apr 9 2017
Sounds likely, I'll set it to block on issue 372245 (fix will land RSN.) Would be good to know what's causing the crash though - a CHECK somewhere?
,
Apr 10 2017
fs@, yes the crash is caused by a CHECK(), see comment #3.
,
Apr 10 2017
No, that's a DCHECK - which wouldn't crash in a release in build (which I assume the reporter was running.) So presumably something CHECKs (sans the 'D' prefix) something else/related later on, which causes the crash. It's good to know the exact crash (and whether it's "controlled" or not.)
,
Apr 10 2017
Just tried on trunk with a non-debug build and it doesn't crash. Possibly the CHECK() was changed/removed or whatever underlying bug was fix as the Chrome version from OP was 54.
,
Apr 19 2017
|
||||||||||
►
Sign in to add a comment |
||||||||||
Comment 1 by jmukthavaram@chromium.org
, Nov 3 2016Components: Blink>Forms>Textarea
Labels: M56
Status: Untriaged (was: Unconfirmed)