Status Update
No update yet.
Comments
ma...@glean.co
We see similar symptoms for our app (
MediaError {code: 4, message: 'PIPELINE_ERROR_READ: FFmpegDemuxer: data source error'}
ka...@google.com
Steps to reproduce
================
1) Launched chrome
2) Naviagted to the given url (
3) Pause and play the video after the video played completly able to play for the second time
But observed unable to play video after page reload while the video is playing
Note:-Also tried in M-121 older builds and able to play video after page relaod
Looping ccameron@ to CC list and request for assist further on this issue.
Reporter@ Could you please review above steps and let us know if we missed anything in reproducing the issue and confirm this is the issue you're pointing to?
Note: Requesting you to copy-paste the entire content of "chrome://version/?show-variations-cmd" details to a .txt file format and attach it
Thanks..!
zu...@gmail.com
Can confirm that this issue affects both Web A (
I'm having trouble downgrading the Chrome version, but managed to check that on Opera 116.0.5366.35 (Chromium: 131.0.6778.266) playback works fine. Reports are coming only from users with Chromium 132.
Is there any workaround, or is service worker streaming using Partial Content completely broken? We are considering disabling video streaming altogether for the affected users and using download-then-play as a fallback.
co...@electronjs.org
pe...@google.com
Thank you for providing more feedback. Adding the requester to the CC list.
ka...@google.com
=================
Able to reproduce the issue on reported chrome version #132.0.6834.84 using Windows 11 arm64, Linux debian and Mac 14.7.2 as per steps in
Observed unable to play video after page reload while the video is playing
Issue not found in firefox browser
Note:- On multiple reloading attempts if the video plays well while clicking on play button then it is considered as good behaviour. If the video got stucked then it is considered as bad behaviour.
Reproducible:
==========
Canary- 134.0.6972.0
Dev - 134.0.6958.2
Beta - 133.0.6943.16
Not Reproducible:
==========
Stable - 131.0.6778.265
Bisect Information:
---------------------------------
Good Build: 132.0.6804.0
Bad Build: 132.0.6809.0
Bisect Script: python bisect_builds.py -o -a win64 -g 132.0.6804.0 -b 132.0.6809.0
CHANGELOG URL:
Suspect:
Change-Id: I712128d82bb7e1971548f22aaadfdf31a7393ad6
Reviewed-on:
Adding RBS for M132, if not required please remove the label.
dtapuska@ Please help us in re-assigning if this is not related to your change.
Thanks..!
pe...@google.com
This issue appears to be blocking an upcoming release and is therefore an Urgent Release Blocking Issue as per
If this is not a release blocking issue, please adjust the release block field. Adjusting the priority will have no affect, P0 will be re-applied whilever this is marked as a release blocking issue.
dt...@chromium.org
ap...@google.com
Project: chromium/src
Branch: main
Author: Dave Tapuska <
Link:
[media] Fix loading error from service workers
Expand for full commit details
[media] Fix loading error from service workers
In https://chromium-review.googlesource.com/c/chromium/src/+/5962517
a validity check was change to use SecurityOrigin::AreSameOrigin since
KURLs were now being used. This had different behavior for two null
origins. For null origins an unique opaque nonce is created when creating a SecurityOrigin. If both are null (when loaded from a service worker) treat the data origin as valid. Add a test.
Bug: 390581541
Change-Id: Ie72d39db7c3fc2afaf643c58ef5f578290a3dd8a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6190868
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Commit-Position: refs/heads/main@{#1409952}
Files:
- M
third_party/blink/renderer/platform/media/url_index.cc - M
third_party/blink/renderer/platform/media/url_index_unittest.cc
Hash: bbc460b4e78c8d1b3aeb28d9263c3f39a9f45639
Date: Wed Jan 22 13:59:14 2025
dt...@chromium.org
co...@electronjs.org
It looks like this didn't quite fix the issue Electron is experiencing - if we load two concurrent videos from a local protocol they still fail to play. This is fixed by changing the src - it only happens when the two sources are identical.
illustrates the issue - if there's anything we can do to help we're happy to! Based on our investigation this was also introduced by the above CL.
dt...@chromium.org
co...@electronjs.org
Working on it, but it looks like the issue is in the same place as the one you just fixed - previously the logic compared data_origin_ == origin directly in UrlData::ValidateDataOrigin, which would return true for free://video and free://video.
It looks like SecurityOrigin::SecurityOrigin::AreSameOrigin(data_origin_, origin) wouldn't consider those the same origin and thus return false. Is there a path forward to handle that case for custom protocols? If I change the conditional to (just for illustration purposes) data_origin_.GetString() == origin.GetString() the problem is resolved.
ch...@microsoft.com
Will the fix be cherry-picked to 132/Stable?
ch...@microsoft.com
ka...@google.com
Observed able to play video after page reload while the video is playing
Hence, the fix is working as expected and adding verified labels
Attaching screencast for reference
Thanks..!!
dt...@chromium.org
pe...@google.com
M133 merge request created. Please update crbug/392073596 to have this merge reviewed.
*This merge request uses Chrome's new merge process. Find more information at
pe...@google.com
M132 merge request created. Please update crbug/392073388 to have this merge reviewed.
*This merge request uses Chrome's new merge process. Find more information at
pe...@google.com
This release blocking issue appears to be targeted for one or more milestones which may have already branched:
- M132, which branched on 2024-11-11 (Chromium branch: 6834, Chromium branch position: 1381561)
- M133, which branched on 2025-01-06 (Chromium branch: 6943, Chromium branch position: 1402768)
Because this issue was marked as fixed on or after branch day, a merge of any CLs which landed on or after branch day may be required.
If no merge is needed (e.g. the necessary CLs are already present in the relevant branch), please remove TBD-## from the Merge field and replace it with NA-## (where ## corresponds to the milestone under evaluation). If a merge is necessary, the requested milestone(s) to the Merge-Request field. If you're not sure, reach out to the relevant release manager (can be found at
To learn more about the merge process, including how to land any required merges, see
ap...@google.com
Project: chromium/src
Branch: refs/branch-heads/6834
Author: Dave Tapuska <
Link:
[M132 Merge] [media] Fix loading error from service workers
Expand for full commit details
[M132 Merge] [media] Fix loading error from service workers
In https://chromium-review.googlesource.com/c/chromium/src/+/5962517
a validity check was change to use SecurityOrigin::AreSameOrigin since
KURLs were now being used. This had different behavior for two null
origins. For null origins an unique opaque nonce is created when creating a SecurityOrigin. If both are null (when loaded from a service worker) treat the data origin as valid. Add a test.
(cherry picked from commit bbc460b4e78c8d1b3aeb28d9263c3f39a9f45639)
Bug: 390581541, 392073388
Change-Id: Ie72d39db7c3fc2afaf643c58ef5f578290a3dd8a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6190868
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Original-Commit-Position: refs/heads/main@{#1409952}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6198821
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Cr-Commit-Position: refs/branch-heads/6834@{#4262}
Cr-Branched-From: 47a3549fac11ee8cb7be6606001ede605b302b9f-refs/heads/main@{#1381561}
Files:
- M
third_party/blink/renderer/platform/media/url_index.cc - M
third_party/blink/renderer/platform/media/url_index_unittest.cc
Hash: d5ad377f4f91b0853504fe89340260570e134bf1
Date: Fri Jan 24 13:41:52 2025
ap...@google.com
Project: chromium/src
Branch: refs/branch-heads/6943
Author: Dave Tapuska <
Link:
[M133 Merge] [media] Fix loading error from service workers
Expand for full commit details
[M133 Merge] [media] Fix loading error from service workers
In https://chromium-review.googlesource.com/c/chromium/src/+/5962517
a validity check was change to use SecurityOrigin::AreSameOrigin since
KURLs were now being used. This had different behavior for two null
origins. For null origins an unique opaque nonce is created when creating a SecurityOrigin. If both are null (when loaded from a service worker) treat the data origin as valid. Add a test.
(cherry picked from commit bbc460b4e78c8d1b3aeb28d9263c3f39a9f45639)
Bug: 390581541, 392073596
Change-Id: Ie72d39db7c3fc2afaf643c58ef5f578290a3dd8a
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6190868
Reviewed-by: Daniel Cheng <dcheng@chromium.org>
Commit-Queue: Dave Tapuska <dtapuska@chromium.org>
Cr-Original-Commit-Position: refs/heads/main@{#1409952}
Reviewed-on: https://chromium-review.googlesource.com/c/chromium/src/+/6198525
Commit-Queue: Daniel Cheng <dcheng@chromium.org>
Bot-Commit: Rubber Stamper <rubber-stamper@appspot.gserviceaccount.com>
Cr-Commit-Position: refs/branch-heads/6943@{#831}
Cr-Branched-From: 72dd0b377c099e1e0230cc7345d5a5125b46ae7d-refs/heads/main@{#1402768}
Files:
- M
third_party/blink/renderer/platform/media/url_index.cc - M
third_party/blink/renderer/platform/media/url_index_unittest.cc
Hash: 495382a77776864f69fbeaa51c028536ab647bc5
Date: Fri Jan 24 13:59:06 2025
ka...@google.com
Observed able to play video after page reload while the video is playing
Hence, the fix is working as expected and adding verified labels
Attaching screencast for reference
Thanks..!!
dk...@google.com
nu...@gmail.com
dt...@chromium.org
al...@google.com
Devices used:
Samsung Galaxy S20 (SM-G980F) / TP1A.220624.014
PIxle 9 Pro Fold/ AP4A.250105.002.C1
ka...@google.com
Observed able to play video after page reload while the video is playing
Hence, the fix is working as expected and adding verified labels
Attaching screencast for reference
Thanks..!!
Description
Steps to reproduce the problem
Try to play cached video on your own example:https://googlechrome.github.io/samples/service-worker/prefetch-video/ . It won't play on second time.
Problem Description
Telegram Web highly relies on Service Worker and
Range+Content-Rangeheaders, as it's the main method how application can stream the video without fully loading it. I'm getting too many reports about it starting from 15th of January.Summary
Broken video playback through Service Worker and
206 Partial ContentresponseCustom Questions
Which component does this fall under?
Blink>ServiceWorker
Does this work in other browsers?
Yes - This is just a Chrome problem
Additional Data
Category: API
Chrome Channel: Stable
Regression: Yes