Video element loading UI triggered with MSE blob attached but not preloading
Reported by
jus...@mux.com,
Jun 12 2018
|
|||||||||||||||
Issue descriptionUserAgent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_13_5) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/67.0.3396.79 Safari/537.36 Steps to reproduce the problem: 1. Add a video element to your page, set to preload=none 2. Attach a `blob:` to the src of the video element, but do not fill the buffer. Media-internals details on the player: ``` render_id: 155 player_id: 428 origin_url: http://localhost:3000/ frame_url: [...] frame_title: Asset url: blob:http://localhost:3000/27227cf8-9ca5-4346-bb03-170393b1777f info: ChunkDemuxer: buffering by DTS pipeline_state: kStarting ``` 3. Do not press play on the player (there is no play button any way, but do not click the player). 4. video.networkState is set to 2, and the UI shows what I'm assuming is the loading state of the new video element UI. See attachment What is the expected behavior? In this state, since the buffer is not being actively filled of the blob source, the UI should present a play button, waiting for the viewer to attempt playback. What went wrong? The UI does not show a play button, but implies to the user that the video is forever loading (even though it is not loading). Filling the buffer eventually would make the player show the static play button, which is what I would have expected otherwise. It seems that this state is entered even if preloading is on, and remains "loading" until the buffer has been filled for the readyState to change. This should not happen, especially in the case that the user has not even attempted to play back the video, as in the current state, it does not give the viewer any indication that they should attempt to press play to start playback. Did this work before? N/A Chrome version: 67.0.3396.79 Channel: stable OS Version: OS X 10.13.5 Flash Version: This wasn't a problem previously because there wasn't this "loading" state. However, adding it in has caused some of our UIs to have regressions.
,
Jun 13 2018
,
Jun 13 2018
@Reporter: Please provide sample URL/test file containing above steps. This would help in further triaging of the issue. Thanks!
,
Jun 13 2018
Certainly! See attached. I tried playing around with the MediaSource, and it seems that the loading animation does not disappear until the player's readyState changes. As I mentioned in the ticket (and after thinking), it seems like the controls enter this state if the readyState is not indicating ready for playback as soon as you start filling this buffer (or give the video element a simple MP4 source), before user or API interaction (i.e. calling play).
,
Jun 13 2018
Thank you for providing more feedback. Adding the requester to the cc list. For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot
,
Jun 14 2018
Able to reproduce the issue on the reported chrome 67.0.3396.79,latest chrome 69.0.3457.0 using Windows10,Mac OS 10.13.5 ,Ubuntu14.04. Below is the Manual bisect information for same. Bisect Info: ================ Good build: 67.0.3396.3 Bad build: 67.0.3396.7 CHANGELOG URL: https://chromium.googlesource.com/chromium/src/+log/67.0.3396.3..67.0.3396.7?pretty=fuller&n=10000 Suspect: https://chromium-review.googlesource.com/c/chromium/src/+/993757 Reviewed-on: https://chromium-review.googlesource.com/993757 beccahughes:Please confirm the issue and help in re-assigning if it is not related to your change. Thanks!
,
Jun 14 2018
,
Jun 14 2018
Changing to M68 since M67 is already out at 100% and this is a P2
,
Jun 14 2018
,
Jun 15 2018
So the underlying issue here is that the video's networkState gets stuck as NETWORK_LOADING. This is not a new issue; it's just made more visible with the controls displaying a loading animation when we're in the NETWORK_LOADING state. I did a manual bisect and the culprit cl is crrev.com/c/832936. +mek@ (owner of culprit CL). Attached is a test html file
,
Jun 15 2018
Are you sure my CL is to blame? The effect I'd expect my CL to have is that before it loading your test file from a file:// URL would not work at all, while after it it would at least start loading. From a non-opaque origin (i.e. not file:// or sandboxed iframes) there shouldn't be a difference at all...
,
Jun 15 2018
Yeah, pretty sure my CL has nothing to do with it. Pre my CL when loaded from a non-opaque origin I see the exact same behavior as post my CL.
,
Jun 15 2018
,
Jun 15 2018
Ah, you're right. Sorry, I was looking at a test file through the file:/// URI for the bisect. Re-bisecting with the test file over http. Thanks!
,
Jun 18 2018
Friendly ping to get an update as stable release is coming soon and this bug is marked as RBS for M68. Thanks..! ----------
,
Jun 22 2018
I looked more into it, and the initial test I was doing with the MSE test file was actually WAI. However, there is still an issue where a video tag with preload=none and a cross-origin source will also report a NETWORK_LOADING networkState. This is a bug and was recently introduced by crrev.com/c/1015794. Assigning to the owner of that CL. Attached is a test file for the issue. Thanks!
,
Jun 22 2018
Also of note is that fixing this issue won't fix the exact problem shown in the bug description, but that is mitigated by the updated loading animation, which shows the play button.
,
Jun 26 2018
Issue 842663 has been merged into this issue.
,
Jun 29 2018
Hubbe@, Friendly ping to get an update on this issue as per C#16,17 it is marked as RBS for M68. Thanks..!
,
Jul 3
Bulk update: M68 stable cut is scheduled for July 19th. This issue is marked as RB-Stable, so please take a look at it before. Thanks!
,
Jul 12
Gentle ping to get an update on this issue as per C#16,17 it is marked as RBS for M68. Thanks..!
,
Jul 17
I'm confused, the example in #16 uses a nonexistant video file. An error callback should be generated, but I don't know if the network state is guaranteed to be in any particular state at/after the error callback.
,
Jul 17
Sorry that was a confusing example. It actually doesn't matter whether the file exists or not, since the video isn't preloaded anyway. It just needs to be a cross-origin source. Attached is the same example but with an actual video
,
Jul 20
This is not a M68 regression and current M67 stable has this issue. Hence punting this to M69.
,
Jul 31
Friendly ping to get an update on this issue as it is marked as RBS. Thanks..!
,
Aug 3
The following revision refers to this bug: https://chromium.googlesource.com/chromium/src.git/+/1b9596a2788c687bca11150bd7f0ae5094ecd1ff commit 1b9596a2788c687bca11150bd7f0ae5094ecd1ff Author: Fredrik Hubinette <hubbe@google.com> Date: Fri Aug 03 17:54:51 2018 No need to hide network states if preload = none We hide some network state changes when loading cross-origin videos. The idea is that non-videos will look exactly like non-existing resources. However, if preload=none, no loading is actually occuring, so there is no reason to hide the preload state. Also, since the player will not naturally progress to an error or "have metadata" stage, it will be stuck loading without this patch. Bug: 852119 Change-Id: I660b6167e1783dae79c90aa5479c504f9d302a6b Reviewed-on: https://chromium-review.googlesource.com/1149143 Reviewed-by: Mounir Lamouri <mlamouri@chromium.org> Commit-Queue: Fredrik Hubinette <hubbe@chromium.org> Cr-Commit-Position: refs/heads/master@{#580594} [modify] https://crrev.com/1b9596a2788c687bca11150bd7f0ae5094ecd1ff/third_party/WebKit/LayoutTests/http/tests/media/media-load-nonmedia-crossorigin.html [modify] https://crrev.com/1b9596a2788c687bca11150bd7f0ae5094ecd1ff/third_party/blink/renderer/core/html/media/html_media_element.cc
,
Aug 7
M69 Stable promotion is coming VERY soon. Your bug is labelled as Stable ReleaseBlock, pls make sure to land the fix and request a merge into the release branch ASAP. Thank you.
,
Aug 8
This issue has been exists since M67, not a blocker for M69. Pls target fix for M70.
,
Aug 21
,
Aug 30
Issue 879137 has been merged into this issue. |
|||||||||||||||
►
Sign in to add a comment |
|||||||||||||||
Comment 1 by jus...@mux.com
, Jun 12 2018166 KB
166 KB View Download