[Webkit-unassigned] [Bug 154240] New: AX: Overlapping WebVTT cues are not resolved correctly

[bugzilla-daemon at webkit.org]

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

            Bug ID: 154240
           Summary: AX: Overlapping WebVTT cues are not resolved correctly
    Classification: Unclassified
           Product: WebKit
           Version: WebKit Nightly Build
          Hardware: All
                OS: All
            Status: NEW
          Severity: Normal
          Priority: P2
         Component: Accessibility
          Assignee: webkit-unassigned at lists.webkit.org
          Reporter: rgovostes+wk at gmail.com
                CC: webkit-bug-importer at group.apple.com

The WebVTT spec says,

> 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.

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) bug 136627 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.

-- 
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://lists.webkit.org/pipermail/webkit-unassigned/attachments/20160215/91206900/attachment-0001.html>