1738877 - Warn on badly used browser.webRequest.filterResponseData

Status: RESOLVED WONTFIX

(WebExtensions :: Request Handling, enhancement)

Description

[Michał Wadas]

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:94.0) Gecko/20100101 Firefox/94.0

Steps to reproduce:

I had following code:

window.browser.webRequest.onBeforeRequest.addListener(
(details) => {
const filter = window.browser.webRequest.filterResponseData(details.requestId);
if (!details.url.includes('/some/url')) {
return;
}
filter.ondata ...
})

Actual results:

All requests not-matching /some/url silently failed.

Expected results:

I would expect warning.

Another option would be to extend signature of browser.webRequest.filterResponseData with second argument in form of:

{
        ondata?: (data: StreamFilterEventData) => void;
        onstart?: (data: StreamFilterEventData) => void;
        onstop?: (data: StreamFilterEventData) => void;
        onerror?: (data: StreamFilterEventData) => void;
}

Comment 1

[BugBot [:suhaib / :marco]]

The Bugbug bot thinks this bug should belong to the 'WebExtensions::Request Handling' component, and is moving the bug to that component. Please revert this change in case you think the bot is wrong.

Comment 2

[Rob Wu [:robwu]]

This is not a defect with the API, but a bug with the extension. We cannot guess the intent of the extension, but we could try to improve docs to help extension developers to do the right thing.

The documentation can be improved to emphasize that once the filterResponseData has been created, that the extension is given full control over response, and that it should have an ondata listener to process the stream (even if it's just filter.write(event.data)) and the extension should be calling close() or disconnect().

Richard, could you improve the docs?

https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/filterResponseData
https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/API/webRequest/StreamFilter

Comment 3

[Richard Bloor]

I've created Clarify behavior of webRequest.filterResponseData() #10432 to cover this requirement.

Comment 4

[Michał Wadas]

This is not a defect with the API, but a bug with the extension.

I would argue that well designed API should be hard to misuse. If it's necessary to register events on event listener, event registration should be possible in .filterResponseData.

Comment 5

[Rob Wu [:robwu]]

Documentation fixed by https://github.com/mdn/content/pull/12349