[Webkit-unassigned] [Bug 94651] ASSERT reached when TextTrack.mode is set to DISABLED

bugzilla-daemon at webkit.org bugzilla-daemon at webkit.org
Wed Sep 5 05:49:30 PDT 2012


https://bugs.webkit.org/show_bug.cgi?id=94651


Anna Cavender <annacc at chromium.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Summary|Occasional crashes when     |ASSERT reached when
                   |TextTrack.mode is set to    |TextTrack.mode is set to
                   |DISABLED during playback    |DISABLED
            Product|Security                    |WebKit
            Version|Other                       |420+
          Component|Security                    |Media Elements
         AssignedTo|webkit-security-unassigned@ |webkit-unassigned at lists.web
                   |lists.webkit.org            |kit.org
              Group|Security-Sensitive          |




--- Comment #5 from Anna Cavender <annacc at chromium.org>  2012-09-05 05:49:42 PST ---
I now have a better understanding of this bug, and a fix!

Turns out that when a TextTrack mode is set to 'showing' or 'hidden', the TextTrack's cues are added to HTMLMediaElement's cueTree regardless of whether they might already have been added previously, creating duplicates.  When the TextTrack's mode changes to 'disabled' textTrackModeChanged() removes the cues, but not the duplicates.  Those cues are then still considered to be active (and they continue have references in m_currentlyActiveCues) and then the ASSERT(cue->isActive()); catches the problem in MediaControlTextTrackContainerElement::updateDisplay().

This was revealed with the new CC button because as the user toggles the button, default tracks start out showingByDefault (i.e. showing), then become hidden (and are added to the cueTree again!), then become showing (added to the cueTree a third time!), and then become disabled, resulting in problems.

The fact that default tracks follow this strange path (showingByDefault->hidden->showing->disabled) is a bug in the spec.

-- 
Configure bugmail: https://bugs.webkit.org/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.


More information about the webkit-unassigned mailing list