(In reply to Jean-Yves Avenard [:jya] from comment #10) > > Depends on D92124 > > I'm confused by this comment. > > The way I read it, caching is blocked, we suspended more caching to occur and we fake the move of readyState when in fact it doesn't happen. That seems to just be a workaround to a logic error in the cache and bypassing a more serious bug. The forced transition exists for [ages](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/html/HTMLMediaElement.cpp#5913-5925). In fact, this force transition occurs everytime once a cache-stream gets [suspended](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/media/MediaCache.cpp#1569,1581), as long as the first-frame of the video is loaded. In this case, this force transition occurs when loading the first cache-stream (line 75-79, 171 in attachment 9178823 [details]), without applying the patch. The web page asks to use [`video.preload="auto"`](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/web-platform/tests/html/canvas/resources/canvas-tests.js#147,160,173) ([wpt #23998](https://github.com/web-platform-tests/wpt/pull/23998/files)) so media-cache tries to download as much data as it can. But the cache size is too small. The cache-size is only [1000 KB]((https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/profiles/unittest-required/user.js#154)) while the [video](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/web-platform/tests/media/movie_300.ogv) size is 2.3 MB. The forced transition works for years without applying the patch. Bug 755533 tries to solve the same problem. The force transition is first made in that bug. I guess this is an edge case it leaves. This patch only affects the cloned stream, which clones itself from a stream that is downloading data and sharing the data with it. The force transition only take place when the [first frame](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/html/HTMLMediaElement.cpp#5892-5896) is loaded. So the "canplaythrough" won't be fired when there is no frame to play. It has at least the first frame. What this patch tries to do is to align with the policy that already exists, when the cache gets stuck. Aside form that, it doesn't break the [spec](https://www.w3.org/TR/2011/WD-html5-20110113/video.html#attr-media-preload) for `video.preload="auto"`: > Hints to the user agent that the user agent can put the user's needs first without risk to the server, up to and including optimistically downloading the entire resource.
Bug 1646719 Comment 11 Edit History
Note: The actual edited comment in the bug view page will always show the original commenter’s name and original timestamp.
(In reply to Jean-Yves Avenard [:jya] from comment #10) > > Depends on D92124 > > I'm confused by this comment. > > The way I read it, caching is blocked, we suspended more caching to occur and we fake the move of readyState when in fact it doesn't happen. That seems to just be a workaround to a logic error in the cache and bypassing a more serious bug. The forced transition exists for [ages](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/html/HTMLMediaElement.cpp#5913-5925). In fact, this force transition occurs everytime once a cache-stream gets [suspended](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/media/MediaCache.cpp#1569,1581), as long as the first-frame of the video is loaded. In this case, this force transition occurs when loading the first cache-stream (line 75-79, 171 in attachment 9178823 [details]), without applying the patch. The web page asks to use [`video.preload="auto"`](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/web-platform/tests/html/canvas/resources/canvas-tests.js#147,160,173) ([wpt #23998](https://github.com/web-platform-tests/wpt/pull/23998/files)) so media-cache tries to download as much data as it can. But the cache size is too small. The cache-size is only [1000 KB](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/profiles/unittest-required/user.js#154) while the [video](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/web-platform/tests/media/movie_300.ogv) size is 2.3 MB. The forced transition works for years without applying the patch. Bug 755533 tries to solve the same problem. The force transition is first made in that bug. I guess this is an edge case it leaves. This patch only affects the cloned stream, which clones itself from a stream that is downloading data and sharing the data with it. The force transition only take place when the [first frame](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/html/HTMLMediaElement.cpp#5892-5896) is loaded. So the "canplaythrough" won't be fired when there is no frame to play. It has at least the first frame. What this patch tries to do is to align with the policy that already exists, when the cache gets stuck. Aside form that, it doesn't break the [spec](https://www.w3.org/TR/2011/WD-html5-20110113/video.html#attr-media-preload) for `video.preload="auto"`: > Hints to the user agent that the user agent can put the user's needs first without risk to the server, up to and including optimistically downloading the entire resource.
(In reply to Jean-Yves Avenard [:jya] from comment #10) > > Depends on D92124 > > I'm confused by this comment. > > The way I read it, caching is blocked, we suspended more caching to occur and we fake the move of readyState when in fact it doesn't happen. That seems to just be a workaround to a logic error in the cache and bypassing a more serious bug. The forced transition exists for [ages](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/html/HTMLMediaElement.cpp#5913-5925). In fact, this force transition occurs everytime once a cache-stream gets [suspended](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/media/MediaCache.cpp#1569,1581), as long as the first-frame of the video is loaded. In this case, this force transition occurs when loading the first cache-stream (line 75-79, 171 in attachment 9178823 [details]), without applying the patch. The web page asks to use [`video.preload="auto"`](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/web-platform/tests/html/canvas/resources/canvas-tests.js#147,160,173) ([wpt #23998](https://github.com/web-platform-tests/wpt/pull/23998/files)) so media-cache tries to download as much data as it can. But the cache size is too small. The cache-size is only [1000 KB](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/profiles/unittest-required/user.js#154) while the [video](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/web-platform/tests/media/movie_300.ogv) size is 2.3 MB. The forced transition works for years without applying the patch. Bug 755533 tries to solve the same problem. The force transition is first made in that bug. I guess this is an edge case it leaves. This patch only affects the cloned stream, which is cloned from a stream that is downloading data and sharing the data with it. The force transition only take place when the [first frame](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/html/HTMLMediaElement.cpp#5892-5896) is loaded. So the "canplaythrough" won't be fired when there is no frame to play. It has at least the first frame. What this patch tries to do is to align with the policy that already exists, when the cache gets stuck. Aside form that, it doesn't break the [spec](https://www.w3.org/TR/2011/WD-html5-20110113/video.html#attr-media-preload) for `video.preload="auto"`: > Hints to the user agent that the user agent can put the user's needs first without risk to the server, up to and including optimistically downloading the entire resource.
(In reply to Jean-Yves Avenard [:jya] from comment #10) > > Depends on D92124 > > I'm confused by this comment. > > The way I read it, caching is blocked, we suspended more caching to occur and we fake the move of readyState when in fact it doesn't happen. That seems to just be a workaround to a logic error in the cache and bypassing a more serious bug. The forced transition exists for [ages](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/html/HTMLMediaElement.cpp#5913-5925). In fact, this force transition occurs everytime once a cache-stream gets [suspended](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/media/MediaCache.cpp#1569,1581), as long as the first-frame of the video is loaded. In this case, this force transition occurs when loading the first cache-stream (line 75-79, 171 in attachment 9178823 [details]), without applying the patch. The web page asks to use [`video.preload="auto"`](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/web-platform/tests/html/canvas/resources/canvas-tests.js#147,160,173) ([wpt #23998](https://github.com/web-platform-tests/wpt/pull/23998/files)) so media-cache tries to download as much data as it can. But the cache size is too small. The cache-size is only [1000 KB](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/profiles/unittest-required/user.js#154) while the [video](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/testing/web-platform/tests/media/movie_300.ogv) size is 2.3 MB. The forced transition works for years without applying the patch. Bug 755533 tries to solve the same problem. The force transition is first made in that bug. I guess this is an edge case it leaves. This patch only affects the cloned stream, which is cloned from a stream that is downloading data and sharing the data with it. The force transition only take place after the [first frame](https://searchfox.org/mozilla-central/rev/35245411b9e8a911fe3f5adb0632c3394f8b4ccb/dom/html/HTMLMediaElement.cpp#5892-5896) is loaded. So the "canplaythrough" won't be fired when there is no frame to play. It has at least the first frame. What this patch tries to do is to align with the policy that already exists, when the cache gets stuck. Aside form that, it doesn't break the [spec](https://www.w3.org/TR/2011/WD-html5-20110113/video.html#attr-media-preload) for `video.preload="auto"`: > Hints to the user agent that the user agent can put the user's needs first without risk to the server, up to and including optimistically downloading the entire resource.