Closed Bug 1905388 Opened 8 months ago Closed 7 months ago

Investigate puppeteer test "[requestinterception.spec] request interception Page.setRequestInterception should work with encoded server - 2" failure

Categories

(Remote Protocol :: WebDriver BiDi, task)

task

Tracking

(Not tracked)

RESOLVED WORKSFORME

People

(Reporter: Sasha, Unassigned)

References

()

Details

The puppeteer test [requestinterception.spec] request interception Page.setRequestInterception should work with encoded server - 2 and its copy in cooperative mode are at the moment skipped, but they would fail if enabled even though data URLs are supported.

There're a couple of problems there.
First, it fails at this assertion, because we get 2 notifications because of the missing charset (see bug 1903274). This can be fixed by add charset to data URL (e.g. data:text/html; charset=utf8,<link rel="stylesheet" href="${server.PREFIX}/fonts?helvetica|arial"/>).

After that, we will start failing the next assertion, because instead of network.responseCompleted event, we would send network.fetchError. This happens because the blockedReason we receive NS_ERROR_FAILURE is not listed here, which is likely correct because it's quite generic.

I've experimented a bit and could only make it work with properly existing files, adding query parameters triggers the error. It also didn't really help to use other type of resources like images or scripts.

I was testing a bit, and I think we are hitting opaqueResponseBlocking, which can be turned off with the pref browser.opaqueResponseBlocking. DevTools netmonitor already has a few issues when trying to handle responses blocked via ORB, we usually show very unhelpful error messages. See for instance Bug 1822090.

Then the overall question is: should a response blocked via ORB in Firefox be considered as a fetch error or a response completed?

See Also: → 1822090

The root cause of the issue is that Chrome and Firefox handle the request to the localhost stylesheet differently. Chrome performs the request and leads to a 404 error, whereas Firefox errors the request because of opaque response blocking.

The tests were rewritten https://github.com/puppeteer/puppeteer/pull/12695

Status: NEW → RESOLVED
Closed: 7 months ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.