After some investigation, I think this is a website issue. Here is what happened. First, this site serves differents DOM content between Firefox and Chrome, that is why this site won't cause high CPU usage on Chrome. On Firefox, there are three video elements, the first one is a super tiny video ,which source is `transparency-test.webm`. This is 1*1 video and its duration is 0.04s. This video exists on both Firefox and Chrome, and the site would keep playing this video. (but this is not the cause of high CPU usage) Other two video elements only exist on Firefox (On Chrome, the site serves still images, not video) are `sled-nvme-annimation.mp4` and `sled-connector-animation.mp4`. These two video are also short, their duration are relatively 2s and 3.53s. When a user starts scrolling down the page, the `sled-nvme-annimation.mp4` will start playing, and quickly reaches to the end in 2s. OK, then the bad thing happens. When the video reaches to the end (2s), it would dispatch `ended` event. Then the site (oxide) will set `v.currentTime=2` on that video, which would cause us to seek to 2s. After seeking to 2s, it would [trigger](https://html.spec.whatwg.org/multipage/media.html#dom-media-seek) (from the step11) another `ended` event based on the [spec](https://html.spec.whatwg.org/multipage/media.html#reaches-the-end) (see 3-3). > dispatch `ended` -> oxide set video current time to 2 -> start another seeking -> dispatch `ended` -> ...... Therefore, there will be a loop, a pretty quick loop! By looking the profiled result in comment0, `seeked` event was dispatched 35 times within **0.1s**!! That made the main thread super busy. As the video is short, the seeking would be finished within a very short period of time, and then those events would trigger another seeking done by oxsite. Same thing would happen on another video `sled-connector-animation.mp4`. These two videos would keep dispatching events to main thread and causes very high CPU usage. The solution would be to ask the oxide not to set `v.currentTime = duration` when they receive `ended` event, because it doesn't help anything.
Bug 1743870 Comment 6 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
After some investigation, I think this is a website issue. Here is what happened. First, this site serves differents DOM content between Firefox and Chrome, that is why this site won't cause high CPU usage on Chrome. On Firefox, there are three video elements, the first one is a super tiny video, which source is `transparency-test.webm`. This is 1*1 video and its duration is 0.04s. This video exists on both Firefox and Chrome, and the site would keep playing this video. (but this is not the cause of high CPU usage) Other two video elements only exist on Firefox (On Chrome, the site serves still images, not video) are `sled-nvme-annimation.mp4` and `sled-connector-animation.mp4`. These two video are also short, their duration are relatively 2s and 3.53s. When a user starts scrolling down the page, the `sled-nvme-annimation.mp4` will start playing, and quickly reaches to the end in 2s. OK, then the bad thing happens. When the video reaches to the end (2s), it would dispatch `ended` event. Then the site (oxide) will set `v.currentTime=2` on that video, which would cause us to seek to 2s. After seeking to 2s, it would [trigger](https://html.spec.whatwg.org/multipage/media.html#dom-media-seek) (from the step11) another `ended` event based on the [spec](https://html.spec.whatwg.org/multipage/media.html#reaches-the-end) (see 3-3). > dispatch `ended` -> oxide set video current time to 2 -> start another seeking -> dispatch `ended` -> ...... Therefore, there will be a loop, a pretty quick loop! By looking the profiled result in comment0, `seeked` event was dispatched 35 times within **0.1s**!! That made the main thread super busy. As the video is short, the seeking would be finished within a very short period of time, and then those events would trigger another seeking done by oxsite. Same thing would happen on another video `sled-connector-animation.mp4`. These two videos would keep dispatching events to main thread and causes very high CPU usage. The solution would be to ask the oxide not to set `v.currentTime = duration` when they receive `ended` event, because it doesn't help anything.
After some investigation, I think this is a website issue. Here is what happened. First, this site serves differents DOM content between Firefox and Chrome, that is why this site won't cause high CPU usage on Chrome. On Firefox, there are three video elements, the first one is a super tiny video, which source is `transparency-test.webm`. This is 1*1 video and its duration is 0.04s. This video exists on both Firefox and Chrome, and the site would keep playing this video. (but this is not the cause of high CPU usage) Other two video elements only exist on Firefox (On Chrome, the site serves still images, not video) are `sled-nvme-annimation.mp4` and `sled-connector-animation.mp4`. These two videos are also short, their duration are relatively `2s` and `3.53s`. When a user starts scrolling down the page, the `sled-nvme-annimation.mp4` will start playing, and quickly reaches to the end in 2s. OK, then the bad thing happens. When the video reaches to the end (2s), it would dispatch `ended` event. Then the site (oxide) will set `v.currentTime=2` on that video, which would cause us to seek to 2s. After seeking to 2s, it would [trigger](https://html.spec.whatwg.org/multipage/media.html#dom-media-seek) (from the step11) another `ended` event based on the [spec](https://html.spec.whatwg.org/multipage/media.html#reaches-the-end) (see 3-3). > dispatch `ended` -> oxide set video current time to 2 -> start another seeking -> dispatch `ended` -> ...... Therefore, there will be a loop, a pretty quick loop! By looking the profiled result in comment0, `seeked` event was dispatched 35 times within **0.1s**!! That made the main thread super busy. As the video is short, the seeking would be finished within a very short period of time, and then those events would trigger another seeking done by oxsite. Same thing would happen on another video `sled-connector-animation.mp4`. These two videos would keep dispatching events to main thread and causes very high CPU usage. The solution would be to ask the oxide not to set `v.currentTime = duration` when they receive `ended` event, because it doesn't help anything.