Bug 1551385 Comment 10 Edit History

Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.

### Beta/Release Uplift Approval Request
* **User impact if declined**: When there are some cues having overlapping timestamp, the cue with earlier end time won't be disappear correctly when the time reaches its end time.
* **Is this code covered by automated tests?**: Yes
* **Has the fix been verified in Nightly?**: No
* **Needs manual test from QE?**: Yes
* **If yes, steps to reproduce**: See comment0.
* **List of other uplifts needed**: None
* **Risk to taking this patch**: Low
* **Why is the change risky/not risky? (and alternatives if risky)**: What my change did is to force us to recompute cue display when the number of active cues changes, so it just trigger another display update, we didn't add new functionality in this bug. In addition, we have automation tests for this issue, it would be safe to catch any unexpected regressions.
* **String changes made/needed**: none
### Beta/Release Uplift Approval Request
* **User impact if declined**: When there are some cues having overlapping timestamp, the cue with earlier end time won't disappear correctly when the time reaches its end time.
* **Is this code covered by automated tests?**: Yes
* **Has the fix been verified in Nightly?**: No
* **Needs manual test from QE?**: Yes
* **If yes, steps to reproduce**: See comment0.
* **List of other uplifts needed**: None
* **Risk to taking this patch**: Low
* **Why is the change risky/not risky? (and alternatives if risky)**: What my change did is to force us to recompute cue display when the number of active cues changes, so it just trigger another display update, we didn't add new functionality in this bug. In addition, we have automation tests for this issue, it would be safe to catch any unexpected regressions.
* **String changes made/needed**: none

Back to Bug 1551385 Comment 10