I did more investigation today, I feel this bug should probably a layout bug again. First, in the console, I can see following error ``` # InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable processCuesInternal resource://gre/modules/vtt.jsm:1222 processCues resource://gre/modules/vtt.jsm:1319 processCues resource://gre/modules/WebVTTParserWrapper.jsm:51 get chrome://global/content/elements/videocontrols.js:2282 updateReflowedDimensions chrome://global/content/elements/videocontrols.js:2317 handleControlEvent chrome://global/content/elements/videocontrols.js:929 handleEvent chrome://global/content/elements/videocontrols.js:698 // "get <- updateReflowedDimensions <- handleControlEvent <- handleEvent" repeats N times.... ``` So I did a quick workaround in [here (videocontrols.js)](https://searchfox.org/mozilla-central/rev/73a6abf1aaedbf7613fa90a7f459a8c0dfe5f0ce/toolkit/content/widgets/videocontrols.js#924-933), adding some code to prevent this part from unlimited re-entry. ``` case "resizevideocontrols": if (this.inReflow) { return; } this.inReflow = true; // Since this event come from the layout, this is the only place // we are sure of that probing into layout won't trigger or force // reflow. this.reflowTriggeringCallValidator.isReflowTriggeringPropsAllowed = true; this.updateReflowedDimensions(); this.reflowTriggeringCallValidator.isReflowTriggeringPropsAllowed = false; this.adjustControlSize(); this.updatePictureInPictureToggleDisplay(); this.inReflow = false; break; ``` By doing so, I can see the subtitle showing again, but it would show in the wrong position. But that is not the point, I then observed an interesting thing. For this [video](https://elements-demo-vanilla-l933ni94n-mux.vercel.app/vanilla-video-2.html), if you apply the above change, and seek a place where the subtitle is showing (and keep video paused), then I found that there would be endless `resizecaption` events... `resizecaption` event is [dispatched here](https://searchfox.org/mozilla-central/rev/73a6abf1aaedbf7613fa90a7f459a8c0dfe5f0ce/layout/generic/nsVideoFrame.cpp#288-294), and I then printed the new child size and the old child size for a comparison. ``` DD | width=38400, height=15960, old-width=38977, old-height=16200 DD | width=38400, height=15960, old-width=38977, old-height=16200 DD | width=38977, height=16200, old-width=38400, old-height=15960 DD | width=38977, height=16200, old-width=38400, old-height=15960 ``` You can find that those caption div size changes really quickly, which means we call `nsVideoFrame::Reflow` in a really really quick frequency. That causes a obvious performance degrade, I could feel the UI become very slow and near frozen. I feel that situation shouldn't happen and is probably a root cause of this issue.
Bug 1733232 Comment 27 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
I did more investigation today, I feel this bug should probably a layout bug again. First, in the console, I can see following error ``` # InvalidStateError: An attempt was made to use an object that is not, or is no longer, usable processCuesInternal resource://gre/modules/vtt.jsm:1222 processCues resource://gre/modules/vtt.jsm:1319 processCues resource://gre/modules/WebVTTParserWrapper.jsm:51 get chrome://global/content/elements/videocontrols.js:2282 updateReflowedDimensions chrome://global/content/elements/videocontrols.js:2317 handleControlEvent chrome://global/content/elements/videocontrols.js:929 handleEvent chrome://global/content/elements/videocontrols.js:698 // "get <- updateReflowedDimensions <- handleControlEvent <- handleEvent" repeats N times.... ``` So I did a quick workaround in [here (videocontrols.js)](https://searchfox.org/mozilla-central/rev/73a6abf1aaedbf7613fa90a7f459a8c0dfe5f0ce/toolkit/content/widgets/videocontrols.js#924-933), adding some code to prevent this part from unlimited re-entry. ``` case "resizevideocontrols": if (this.inReflow) { return; } this.inReflow = true; // Since this event come from the layout, this is the only place // we are sure of that probing into layout won't trigger or force // reflow. this.reflowTriggeringCallValidator.isReflowTriggeringPropsAllowed = true; this.updateReflowedDimensions(); this.reflowTriggeringCallValidator.isReflowTriggeringPropsAllowed = false; this.adjustControlSize(); this.updatePictureInPictureToggleDisplay(); this.inReflow = false; break; ``` By doing so, I can see the subtitle showing again, but it would show in the wrong position. But that is not the point, I then observed an interesting thing. For this [video](https://elements-demo-vanilla-l933ni94n-mux.vercel.app/vanilla-video-2.html), if you apply the above change, and seek to a place where a subtitle is showing (and keep video paused), then I found that there would be endless `resizecaption` events... `resizecaption` event is [dispatched here](https://searchfox.org/mozilla-central/rev/73a6abf1aaedbf7613fa90a7f459a8c0dfe5f0ce/layout/generic/nsVideoFrame.cpp#288-294), and I then printed the new child size and the old child size for a comparison. ``` DD | width=38400, height=15960, old-width=38977, old-height=16200 DD | width=38400, height=15960, old-width=38977, old-height=16200 DD | width=38977, height=16200, old-width=38400, old-height=15960 DD | width=38977, height=16200, old-width=38400, old-height=15960 ``` You can find that those caption div size changes really quickly, which means we call `nsVideoFrame::Reflow` in a really really quick frequency. That causes a obvious performance degrade, I could feel the UI become very slow and near frozen. I feel that situation shouldn't happen and is probably a root cause of this issue.