This is used in the rendering model to keep the display of cues consistent.

As far as I can tell this is basically the computed DOM structure of the parsed cue text data. What I would think would need to happen for this bug to get done is to have the computed DOM structure generated lazily and have some kind of mechanism for marking dirty cue text that needs to be re-computed.

I've renamed mCueDiv to mDisplayState to keep more inline with the spec. I've also introduced mReset in order to tell when we need to rebuild the computed cuetext of the TextTrackCue. The code that will leverage this will land in bug 865407.

Comment on attachment 768503 [details] [diff] [review] v1: Implement TextTrackCue::DisplayState Review of attachment 768503 [details] [diff] [review]: ----------------------------------------------------------------- r=me ::: content/media/TextTrackCue.h @@ +341,4 @@ > int mLine; > TextTrackCueAlign mAlign; > > + // Holds the computed CSS boxes that represent the parsed cue text. We're using this to attach elements, not Frames, so I don't think it's correct to call these 'computed CSS boxes'. Those are generated downstream by the layout engine.

Carring forward r=rillian. - Updated mDisplayState's comment to reflect that we are generating DOM elements. - Updated mReset's comment to reflect that it is set anytime any property that affects TextTrackCue's rendering is changed.

Try push: https://tbpl.mozilla.org/?tree=Try&rev=9554a409313d

Try looks green. Should we get anyone else to review this Ralph?

In our weekly meeting Ralph said that his reviewing of this was enough. Marking for checkin now.