`new Response(new ReadableStream()).text()` can be aborted too soon by cycle collection
Categories
(Core :: DOM: Networking, defect, P2)
Tracking
()
People
(Reporter: saschanaz, Assigned: saschanaz)
References
(Regression)
Details
(Keywords: regression, Whiteboard: [necko-triaged], [wptsync upstream])
Attachments
(3 files, 1 obsolete file)
|
48 bytes,
text/x-phabricator-request
|
Details | Review | |
|
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-beta+
|
Details | Review |
|
48 bytes,
text/x-phabricator-request
|
phab-bot
:
approval-mozilla-esr128+
|
Details | Review |
var i = 0;
await new Response(new ReadableStream({
pull(c) {
if (i >= 1000) {
c.close();
return;
}
++i;
c.enqueue(new Uint8Array([0]))
TestUtils.gc(); // enabled with dom.testing.testutils.enabled=true
}
})).arrayBuffer();
Expected: An ArrayBuffer with size 1000
Actual on Nightly: An ArrayBuffer with size 1
This is a kinda edge case where the stream is owned only by itself and nobody else. I don't know why anyone would do this rather than purely for testing. (Thus S4 while P2 because it's regression.)
Nothing is strongly holding FetchStreamReader while waiting for OutputStreamHolder. Might want to have a temporary strong reference just as we have mAsyncWaitWorkerRef right now. (And thanks to mAsyncWaitWorkerRef this works fine on workers)
Comment 1•1 year ago
|
||
Set release status flags based on info from the regressing bug 1939295
| Assignee | ||
Comment 2•1 year ago
|
||
Looks like this regression could be covered but was hidden by wpt-sync's aggressive test result additions... https://searchfox.org/mozilla-central/rev/9f9fa5d2cb72b12ac7e168b7f6ee9820f63291e9/testing/web-platform/meta/service-workers/service-worker/fetch-event-respond-with-readable-stream.https.html.ini
Updated•1 year ago
|
| Assignee | ||
Comment 3•1 year ago
|
||
Nothing strongly grabs ReadableStream nor FetchStreamReader while waiting for nsIAsyncOutputStream to respond. mAsyncWaitReader should now strongly grab the reader until the output stream responds.
Updated•1 year ago
|
Comment 6•1 year ago
|
||
| bugherder | ||
Comment 8•1 year ago
|
||
The patch landed in nightly and beta is affected.
:saschanaz, is this bug important enough to require an uplift?
- If yes, please nominate the patch for beta approval.
- If no, please set
status-firefox135towontfix.
For more information, please visit BugBot documentation.
| Assignee | ||
Comment 9•1 year ago
|
||
Nothing strongly grabs ReadableStream nor FetchStreamReader while waiting for nsIAsyncOutputStream to respond. mAsyncWaitReader should now strongly grab the reader until the output stream responds.
Original Revision: https://phabricator.services.mozilla.com/D234031
Updated•1 year ago
|
Updated•1 year ago
|
Comment 10•1 year ago
|
||
beta Uplift Approval Request
- User impact if declined: In an edge case one may get incomplete result when consuming a stream
- Code covered by automated testing: yes
- Fix verified in Nightly: yes
- Needs manual QE test: no
- Steps to reproduce for manual QE testing: N/A
- Risk associated with taking this patch: Low
- Explanation of risk level: Minimal changes
- String changes made/needed: No
- Is Android affected?: yes
| Assignee | ||
Updated•1 year ago
|
Updated•1 year ago
|
Comment 11•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Updated•1 year ago
|
| Assignee | ||
Updated•1 year ago
|
| Assignee | ||
Comment 12•1 year ago
|
||
We got a real world report of this regression in bug 1942573.
| Assignee | ||
Comment 13•1 year ago
|
||
Nothing strongly grabs ReadableStream nor FetchStreamReader while waiting for nsIAsyncOutputStream to respond. mAsyncWaitReader should now strongly grab the reader until the output stream responds.
Original Revision: https://phabricator.services.mozilla.com/D234031
Updated•1 year ago
|
| Assignee | ||
Comment 14•1 year ago
|
||
Nothing strongly grabs ReadableStream nor FetchStreamReader while waiting for nsIAsyncOutputStream to respond. mAsyncWaitReader should now strongly grab the reader until the output stream responds.
Original Revision: https://phabricator.services.mozilla.com/D234031
Updated•1 year ago
|
Comment 15•1 year ago
|
||
Kagami, if we need to uplift a patch to all of our branches, I think the severity of this bug shouldn't be an S4.
Is the new revision you created just a copy of the patch that was already uplifted to beta? (seems to me at first sight), if so I can manually graft it to mozilla-release and carry over the existing reviewer.
| Assignee | ||
Comment 16•1 year ago
|
||
Let's make it S3. Yes, it's just the same patch, cleanly grafted.
Comment 17•1 year ago
|
||
Comment on attachment 9460495 [details]
Bug 1941210 - Strongly grab FetchStreamReader while waiting for writing r=smaug,jesup
Functional regression in 134, approved for 134.0.2, thanks.
Comment 18•1 year ago
|
||
| uplift | ||
Updated•1 year ago
|
Comment 19•1 year ago
|
||
Kagami, could you provide a release note summarizing the issue please?
You can look at past release notes as a template: https://www.mozilla.org/en-US/firefox/134.0.1/releasenotes/
Thanks
| Assignee | ||
Comment 20•1 year ago
|
||
How about "Fixed an issue where data consumption from service workers may unexpectedly halt."
While technically this doesn't only affect service worker, for now that's the only reported real world case.
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Updated•1 year ago
|
Comment 21•1 year ago
|
||
| uplift | ||
Description
•