<html>
<head>
<base href="https://bugs.webkit.org/" />
</head>
<body><table border="1" cellspacing="0" cellpadding="8">
<tr>
<th>Bug ID</th>
<td><a class="bz_bug_link
bz_status_NEW "
title="NEW - AX: Overlapping WebVTT cues are not resolved correctly"
href="https://bugs.webkit.org/show_bug.cgi?id=154240">154240</a>
</td>
</tr>
<tr>
<th>Summary</th>
<td>AX: Overlapping WebVTT cues are not resolved correctly
</td>
</tr>
<tr>
<th>Classification</th>
<td>Unclassified
</td>
</tr>
<tr>
<th>Product</th>
<td>WebKit
</td>
</tr>
<tr>
<th>Version</th>
<td>WebKit Nightly Build
</td>
</tr>
<tr>
<th>Hardware</th>
<td>All
</td>
</tr>
<tr>
<th>OS</th>
<td>All
</td>
</tr>
<tr>
<th>Status</th>
<td>NEW
</td>
</tr>
<tr>
<th>Severity</th>
<td>Normal
</td>
</tr>
<tr>
<th>Priority</th>
<td>P2
</td>
</tr>
<tr>
<th>Component</th>
<td>Accessibility
</td>
</tr>
<tr>
<th>Assignee</th>
<td>webkit-unassigned@lists.webkit.org
</td>
</tr>
<tr>
<th>Reporter</th>
<td>rgovostes+wk@gmail.com
</td>
</tr>
<tr>
<th>CC</th>
<td>webkit-bug-importer@group.apple.com
</td>
</tr></table>
<p>
<div>
<pre>The WebVTT spec says,
<span class="quote">> If there is a position to which the boxes in boxes can be moved while maintaining the relative positions of the boxes in boxes to each other such that none of the boxes in boxes would overlap any of the boxes in output, and all the boxes in boxes would be within the video’s rendering area, then move the boxes in boxes to the closest such position to their current position, and then jump to the step labeled done positioning below. If there are multiple such positions that are equidistant from their current position, use the highest one amongst them; if there are several at that height, then use the leftmost one amongst them.</span >
This does not appear to be the logic used in the RenderVTTCue::findNonOverlappingPosition implementation. It ignores the relative positions of the cues and simply
1. Slide the most recent cue up (or left for vertical writing direction) until not overlapping with anything
2. Check if it is still within the bounds of the container, if so, stop.
3. Slide the same cue down (or right) until not overlapping with anything.
4. Check if it is still within the bounds of the container, if so, stop.
5. Give up.
Languages with horizontal writing direction would normally expect more recently displayed cues to be slid down, not up. And there is a similar (possibly duplicate) <a class="bz_bug_link
bz_status_NEW "
title="NEW - WebVTT: vertical cue text alignment is the wrong way around"
href="show_bug.cgi?id=136627">bug 136627</a> which claims a similar problem for a language with vertical writing direction.
However even switching steps 1 and 3 would not actually implement the spec, since it still ignores relative positioning.
I think this algorithm would work for correctly showing a new cue without reflowing existing cues. But technically the spec mandates that as well. I think that might require a linear constraint solver.
1. If the current cue should be above (below) the overlapped cue, set the direction to UP (DOWN).
2. Slide the current cue in this direction until it is not overlapping any other cue.
3. Check that the current cue is still within the bounds of the container, otherwise, stop.
4. For each other cue:
5. Check that the current cue is positioned correctly relative to the other cue, if so, continue to next cue
6. If the current cue should be above (below) the other cue, and the direction is DOWN (UP), then stop.
7. Otherwise, continue sliding the current cue in this direction until it is correctly positioned relative to the other cue.
8. Check that the current cue is still within the bounds of the container, otherwise, stop.</pre>
</div>
</p>
<hr>
<span>You are receiving this mail because:</span>
<ul>
<li>You are the assignee for the bug.</li>
</ul>
</body>
</html>