1557300 - Using blocking webRequest APIs causes major performance issues when intercepting data URI requests

Status: RESOLVED DUPLICATE of bug 1630737

(WebExtensions :: Request Handling, defect, P2)

Description

[Gildas Lormeau]

Attachment: files.zip

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

Steps to reproduce:

1 - Unzip the attached file somewhere on the disk
2 - Unzip and install the extension contained into bug-webrequest-file.zip. This extension registers 1000 empty handlers by calling browser.webRequest.onBeforeRequest.addListener(() => { }, { urls: ["<all_urls>"] }, ["blocking"]); 1000 times
3 - Open the index.html page (from the attached zip file). This page contains hundreds of data URIs.

Actual results:

The browser is unresponsive.

Expected results:

The browser should not be unresponsive. This issue does not exist in Chrome. Moreover, it seems that this API does not work with data URI requests, e.g. I wasn't able to cancel them.

Comment 1

[Salar]

I'm confirming this, here is a sample requestDetails being sent:
{ "documentUrl": "moz-nullprincipal:{99fd9ed7-8845-4aa3-ab08-dafae7cf7bd1}", "frameAncestors": [], "frameId": 15032385550, "method": "null", "originUrl": "moz-nullprincipal:{99fd9ed7-8845-4aa3-ab08-dafae7cf7bd1}", "parentFrameId": 15032385537, "requestId": "fakeRequest-436", "tabId": 6, "timeStamp": 1559858482376, "type": "image", "url": "data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD....." }

Comment 2

[Rares Doghi, Desktop QA]

Hi, I managed to reproduce this issue In our latest Nightly version 69.0a1 (2019-06-11) as well Release and Beta using the files attached to this issue. Thanks for reporting it and thanks for the test case provided.

Comment 3

[BugBot [:suhaib / :marco/ :calixte]]

The priority flag is not set for this bug.
:ddurst, could you have a look please?

For more information, please visit auto_nag documentation.

Comment 4

[Jim Mathies [:jimm]]

Eventually the socket process may help here. We can also be smarter about how we handle these requests.

Comment 5

[Andrew Swan [:aswan]]

The duplicate here is newer, but has more information and a concrete plan for addressing this.