This is an archived snapshot of W3C's public bugzilla bug tracker, decommissioned in April 2019. Please see the home page for more details.
"Let n be the number of text tracks whose text track mode is showing and that are in the media element's list of text tracks before track." This doesn't exclude metadata tracks, so if there are lots of metadata tracks and one captions track, that captions track could get a computed line position placing it where it makes no sense.
I filed this bug because I noticed that Blink only considers tracks which are showing *and* are either subtitles or captions, which is not per spec. Actually, this is a problem if there are many captions track but only one has an active cue, too. I wonder why this shouldn't simply return -1, the overlap avoidance will take care of the rest.
Metadata tracks are definitely never rendered, so I agree that they should be excluded, no matter if they are showing or not. The HTML spec has some text towards this interpretation where it defines "Showing": "Showing - Indicates that the text track is active. [..] In addition, for text tracks whose kind is subtitles or captions, the cues are being overlaid on the video as appropriate; for text tracks whose kind is descriptions, the user agent is making the cues available to the user in a non-visual fashion; and for text tracks whose kind is chapters, the user agent is making available to the user a mechanism by which the user can navigate to any point in the media resource by selecting a cue." It might be a good idea to more explicitly follow this in the WebVTT spec, too, and exclude metadata, descriptions and chapter tracks from this *visual* rendering algorithm.