Bug 127134
| Summary: | In-band text track cue duplicate detection should use the cue's original content, not its current content | ||
|---|---|---|---|
| Product: | WebKit | Reporter: | Brendan Long <b.long> |
| Component: | Media | Assignee: | Nobody <webkit-unassigned> |
| Status: | NEW | ||
| Severity: | Normal | CC: | acolwell, eric.carlson, webkit |
| Priority: | P2 | ||
| Version: | 528+ (Nightly build) | ||
| Hardware: | Unspecified | ||
| OS: | Unspecified | ||
Brendan Long
While discussing our duplicate detection behavior for in-band cues on the HTML mailing list, this came up:
> Ok. So existing WebKit behavior will add the cue again if the application
> modified it. That is likely to be surprising to the application developer.
> We definitely need clarification on what the proper behavior should be in
> the spec.
I think the way we should handle this is by comparing cues with the original cue content, not the current cue content, so if we seek backwards and see a cue that already exists, but has been modified, we ignore that cue and just keep the modified one.
| Attachments | ||
|---|---|---|
| Add attachment proposed patch, testcase, etc. |
Gary Katsevman
My old bug https://bugs.webkit.org/show_bug.cgi?id=240549 looks related to this. I would say it's definitely unexpected that the cue shows up again.