Open Bug 1762960 Opened 4 years ago Updated 4 years ago

ReadableStreamDefaultReader.cancel() does not cancel the actual download

Categories

(Core :: Networking, defect, P3)

Firefox 98
defect

Tracking

()

UNCONFIRMED

People

(Reporter: segfault_bilibili, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [necko-triaged])

User Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:98.0) Gecko/20100101 Firefox/98.0

Steps to reproduce:

Open F12 dev panel, enable network throttling (Regular 2G), and then execute the following JS code:

var time = 0;

function logTime(msg, noReset) {
    let newTime = new Date().getTime();
    console.log(`${newTime - time}ms`, msg);
    if (!noReset) time = newTime;
}

async function cancelledFetch() {
    time = new Date().getTime();
    let resp = await fetch("file1");
    logTime("(to be cancelled) fetch");
    let reader = resp.body.getReader();
    logTime("(to be cancelled) getReader");
    let result = await reader.read();
    logTime("(to be cancelled) read", true);
    await reader.cancel();
    logTime("(cancelled)", true);
}

async function test() {
    time = new Date().getTime();
    cancelledFetch(); // not await
    let resp = await fetch("file2");
    logTime("fetch");
    let reader = resp.body.getReader();
    logTime("getReader");
    while (true) {
        let result = await reader.read();
        logTime("read", true);
        if (result.done) break;
    }
    logTime("read finished", true);
}

test();

Actual results:

In the F12 dev panel, both the Network monitoring tab and the JS Console tab seemed to show that reader.cancel() didn't cancel the actual download, although await reader.cancel() didn't throw any error.

In the Network monitoring tab, it seemed that the cancelled file1 was still downloaded. At least some (more than half) part was downloaded, if not whole. Besides, file2 took almost twice the expected time to finish downloading - seemed to be blocked by file1.

In the JS console output, it took much longer time than expected to see first read of file2, probably it's blocked by file1, which is consistent with what's observed in Network tab described above.

Expected results:

After reader.cancel() is called, the actual download should then be cancelled as soon as possible.

The Bugbug bot thinks this bug should belong to the 'Core::Networking' component, and is moving the bug to that component. Please correct in case you think the bot is wrong.

Component: Untriaged → Networking
Product: Firefox → Core
Blocks: fetch
Severity: -- → S3
Priority: -- → P3
Whiteboard: [necko-triaged]
You need to log in before you can comment on or make changes to this bug.