Blob URLs broken on Chrome 71 in headless mode

[williamoliveira]

Steps to reproduce

Tell us about your environment:

• Puppeteer version: 1.9.0
• Platform / OS version: Ubuntu x64
• Node.js version: v10.12.0
• Chrome version: 71.0.3578.20 (beta)

What steps will reproduce the problem?

The smallest example I was able to make:

    await page.evaluate(() => {
      const url = 'data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAAUAAAAFCAYAAACNbyblAAAAHElEQVQI12P4//8/w38GIAXDIBKE0DHxgljNBAAO9TXL0Y4OHwAAAABJRU5ErkJggg=='

      return window.fetch(url)
        .then(res => res.blob())
        .then(blob => URL.createObjectURL(blob))
        .then(url => window.fetch(url)) // crashes here
        .then(res => res.blob())
    })

What is the expected result?
On Chrome 70 or Chrome 71 headfull it works fine

What happens instead?
On Chrome 71 in headless mode I get: Failed to load resource: net::ERR_UNKNOWN_URL_SCHEME

[williamoliveira]

Works on 72

[floribon]

Getting the same error with puppeteer 1.10.0

[jacobweber]

Same issue here, with Mac OS 10.14.1, node 8.12.0, puppeteer 1.10.0 in headless mode only, and whatever version of Chromium is bundled with that (looks like chromium_revision = 599821 in package.json). For me it works in 1.9.0.

[luigi-rosso]

Also seeing this on 1.10.0 and 1.9.0, works in 1.8.0.

[mqaiserm]

Any luck with this guys? I am having the same problem.
Work on Mac but not on Linux.

[floribon]

I ended up downloading chrome-stable instead of using the packed chromium (which I needed anyway as I'm relying on mp4 codecs)

[williamoliveira]

The solution is to download Chrome or Chromium 70 or 72 and set its path on puppetter's config object

[aslushnikov]

This is a regression in our network stack in headless; filed upstream - https://crbug.com/902918

Thanks for reporting this!

[mqaiserm]

Same issue. I downloaded google-chrome-stable (Google Chrome 70.0.3538.77 ) and provided it's path to pupeteer. Same results.

[KfirAlfa]

Works on 72

What is your OS?
For me it does not work, running at Linux

[cancerberoSgx]

same here - fetch('blob:http://localhost:8000/19a6355a-e44c-45c5-9890-cdde443e25f9') is failing in 1.10.0 but was working fine in 0.13.0 - console.error is : ."Failed to load resource: net::ERR_UNKNOWN_URL_SCHEME" - maybe I need to pass a new flag or configuration because of a new policy now ? - Running on arch and ubuntu linux

[sids4ru]

I get this with CesiumJS as well
CesiumGS/cesium#7292

[floribon]

Having the same issue with Chrome stable 71 headless now (after switching off puppeteer, works fine without the headless flag), so it's not only affecting puppeteer.

[elbartostrikesagain]

I am also having problems with this - No problems after updating to Chrome 72 beta though

[aslushnikov]

Looks like this is working fine on newer Chrome; closing this.

[nsleigh]

Still not working on 71 - which version do you think it is working on? How can this be reopened?

[maschwenk]

@nsleigh I think the assumption is that it's closed in 72 beta so it'll be fixed when we tick over to 72

[nsleigh]

But that is at least 20 days away and our end to end testing has been broken for a for long time now. We really need a 71 fix.

[aslushnikov]

@nsleigh this can't be backported to stable channel since it's not a security issue. Can you use beta channel for your e2e tests?

[RafalSkorka]

As a temp workaround for those who run E2E on Jenkins - Xvnc plugin is working great allowing for head mode where the problem does not exist.

[nsleigh]

@aslushnikov I did try the beta and didn't think it was stable (well our test results were worse, I guess that might mean they will fail on 72). How stable is beta? Is it more like a preview?

@RafalSkorka I'll take a look at that, we use Jenkins.

[aslushnikov]

How stable is beta? Is it more like a preview?

Beta is very stable; it can be easily used in a day-to-day life.

[JoshuaCWebDeveloper]

Can confirm that this is fixed in v72. However, I wanted to add a note that I observed about this bug (not sure if it is indicative of another bug that should be reported elsewhere or not):

I encountered this error while using a library that created a web worker similar to this (summarized code):

var w = new window.Worker(blobUrl)

w.onerror = function (event) {
    console.error(event);
}

However, it took me awhile to figure out what was going on, as the error thrown by the library was not very helpful. This is because a) The error from new Worker() (net::ERR_UNKNOWN_URL_SCHEME) was thrown asynchronously (which may be expected), and b) when the onerror handler of the worker was called, it was given an object that was an instance of just Event not ErrorEvent as the docs indicate: https://developer.mozilla.org/en-US/docs/Web/API/Worker. The library expected ErrorEvent specific properties that weren't there and thus produced an unhelpful message that took me while to track down.

It would seem that passing a plain Event object to onerror instead of an ErrorEvent object is in of itself a bug, not sure if it is related to this issue specifically and fixed in v72 or not.

[aslushnikov]

It would seem that passing a plain Event object to onerror instead of an ErrorEvent object is in of itself a bug, not sure if it is related to this issue specifically and fixed in v72 or not.

@JoshuaCWebDeveloper this looks like a Chromium bug; I'd file it to https://crbug.com/new

[JoshuaCWebDeveloper]

Thanks for getting back to me @aslushnikov.

For anyone who is interested: after some further investigation, it seems that a) there is some conflicting info in the docs, b) there is nothing about invalid url handling in the w3 spec, and c) Chrome, Firefox, and Edge all have the same behavior, so in lieu of filing a Chromium bug, I've asked a question on SO for some more input: https://stackoverflow.com/questions/54190092/how-do-i-detect-an-invalid-url-being-given-to-worker

[johanneswilm]

It seems like this now also broken in the latest 72 beta release (72.0.3626.64-1). Previously a fix was switching to the beta channel, but it seems that that now no longer helps.

[nsleigh]

I think I am seeing an issue too, it was ok with 72.0.3626.53 but 72.0.3626.64 seems to have an issue but I am not sure it is the same. Still investigating.

After a bit more investigation I think 72.0.3626.64 is still ok.

[JoshuaCWebDeveloper]

When I installed beta 3 days ago, the version that was installed was 72.0.3626.64. This issue was and still is fixed on that version for me. When I go to check for updates, beta informs me that google chrome is up to date, and that the current version is 72.0.3626.64. I'm not sure where the 72.0.3626.64-1 version referenced by @johanneswilm is coming from.

[johanneswilm]

@JoshuaCWebDeveloper It's probably the same version. I simply downloaded the beta version of chrome that travis downloads on linux and that was the version info the deb-installer gave me.

If it's not the same issue, it is very similar. I had an issue in testing a few weeks ago. I fixed it by simply switching to the chrome beta channel in travis without investigating what was causing it. A few days ago it stopped working, and today I spent some hours trying to find the cause of it, arrived at a worker that was packaged into a blob and from there I found this issue.

[johanneswilm]

Sorry about the confusion. It seems that the issue is that Travis runs webdriver on Chrome 71 even though it downloads and installs Chrome 72 when 'beta' is selected. Will investigate further, but it appears not to be related to this issue.