Mixed Content error when I try to download a blob from offscreen document.

[Robbi]

Hi
I'm trying to generate a link to dowload a file inside an offscreen document.
I'm dealing with some cells of an html table that I want to save in xls format.

The code is very simple:
var fn = file_name + '.xls';
txtFile = '<table>' + myData + '</table>';
const lnk = document.createElement("a");
var file = new Blob([txtFile], {type: 'application/vnd.ms-excel'});
lnk.href = URL.createObjectURL(file);
lnk.download = fn;
lnk.click()

The download starts but is immediately blocked by the browser.
I can manually force the download, but in console I get this ugly error:
"Mixed Content: The site at 'chrome-extension://<extension_id>/' was loaded over a secure connection,
but the file at 'blob:chrome-extension://<extension_id>/b560e56f-dce5-44b6-914c-6b62ca778ac6' was loaded over an insecure connection.
This file should be served over HTTPS. This download has been blocked.
See https://blog.chromium.org/2020/02/protecting-users-from-insecure.html for more details."

Is there a way to avoid this message?
TIA

[wOxxOm]

It's a bug. I guess the only workaround is to use chrome.downloads in the service worker.

[Robbi]

HI @wOxxOm ,
actually I wanted to avoid using this API because I have to add a new permission in the manifest and, if I'm not wrong, this disables the extension.
I haven't tried yet to create a new minimized window to close immediately after download, but I guess the same error will be waiting for me.

Thanks for your reply

[wOxxOm]

Another workaround would be to do the same thing you do now but inside a web_accessible_resources iframe added to the any tab for which your extension has host permissions.

[Robbi]

it's a little complicated.
I'm basically making about thirty requests into a worker within the offscreen document.

It's not a bulk request, but they are 28-31 synchronous requests spaced by a certain number of seconds
Each response is processed with DOMParser and the result is appended as html code to a string.
When the worker has finished processing all requests it returns that string to the service worker which shows the user a notification asking whether to view the output as html or xls.
During this time I may not find any extension pages (or even any tabs in general) open.
In fact, at the start of the "job" I inform the user that he can also browse or close the tab\window from which he made the request but he must not close the browser otherwise the request (the offscreen document and the worker) will be lost.
If the user chooses HTML then I open a new tab and put my generated table inside a placeholder (div). Conversely, if the user chooses the xls format, I start the download from within the off-screen document.

If it has not already been reported, and if you think it might help, I could also open a bug report.

[Jackie Han]

I tested your code. It works in offscreen page. No problem.

--
You received this message because you are subscribed to the Google Groups "Chromium Extensions" group.
To unsubscribe from this group and stop receiving emails from it, send an email to chromium-extens...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/51e72338-6369-486c-ad54-d97cce4d17a5n%40chromium.org.

[Robbi]

Hi @Jackie, no error in console?
I tested with the last version of Canary. The download is blocked (but may be a normal behaviour as the file is a "potentially corupted" xls which might have sone macro inside).
I can force the download manually but I always get that error.
I tryied to open the OSD with reason WORKERS or BLOBS but I don't see any change.

Now that I just got home  I could try with some other chromium based browsers

[Robbi]

I just tried with Canary and Dev from home and... I don't get that error :-)

Next Monday I'll try again from my workplace (which is the ideal environment because I have to use a VPN from home) and let you know.

But the thing is strange...

[Patrick Kettner]

> It's a bug. I guess the only workaround is to use chrome.downloads in the service worker.

@wOxxOm a bug as "that is something in a bug report", or bug as in "that is not working as it should". I believe it should work, and am not able to find a relevant bug - can you share it if you have one?

@Robbi I am not able to replicate it either - would you be able to share an extension that reproduces the issue?

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/chromium-extensions/574b5b28-ec03-41be-a905-dcf4ea71d029n%40chromium.org.

[Robbi]

I no longer get this error even from my workplace.

I don't know what to say... , maybe a restart of the pc helped

That's good, but it's still a mystery.

[Patrick Kettner]

Glad to hear you are no longer seeing the issue - please do reach out if you ever hit it again

[Robbi]

I was no longer able to reproduce the error with MV3 and offscreen document, but I was able to reproduce it consistently with MV2 with both permanent and volatile background scripts.

All in all I'm not crazy yet, not entirely at least :-)

The attached extension has been reduced to the maximum just to replicate the error.

The thing that worries me a bit is that I already have an MV2 version ready (with modifications that have not changed the HTML file generation and download logic) and I really don't want to see this error appear after the update.

The current version in the store doesn't throw that error.

Link to download the extension and a short video:  https://we.tl/t-LdzVIKFrFs

What do you think?

[Robbi]

Forgot to write that I get that error only with Dev and Canary

[Patrick Kettner]

Thanks Robbi!

I was finally able to replicate this. I created a reduced demo, and am able to replicate in canary. I'm not able to replicate it in Dev channel with yours or mine, however. Are you certain it is an issue in dev? if so, can you provide the information in chrome://version?

[wOxxOm]

It can be caused by a new field trial variation which are randomly enabled for different users in different release channels of the browser.

The list is shown (as a command line) in chrome://version/?show-variations-cmd

Try comparing it to a working profile.

[Patrick Kettner]

Ah, great call @wOxxOm! 

tl:dr - its a bug in chrome (not specifically extensions), but only in a subset users in canary and dev

I spoke with the dev that implemented the feature, and he said that it does not seem like it should trigger the logic showing the warning. He asked me to file a bug (which you can see here), and that he would dig into it more. That field trial is only on for some users in dev and canary, and as of now there isn't a known workaround. If you follow that bug, you will be kept up to date on it.

[Robbi]

Hi, I'm going to star that bug, thanks.
As suggested by @wOxxOm I attach some "variations report" from different browsers.

Link to mhtml report files: https://we.tl/t-eAWQuoqBk3

[Patrick Kettner]

Hey Robbi!

I am no longer able to replicate this, could you check and let me know if you are?

[Robbi]

I have not test this issue again because I continued with my migration.

Tomorrow morning (GMT+2) I'll do some tries with Dev and Canary and I'll let you know.

If it helps, I realized that an (unrelated) issue I reported a while ago has been fixed  bug 1178285

[Robbi]

Ok, I don't see the "Mixed Content"  error anymore.

Verified both in Canary 116.0.5791.0  and  Dev 115.0.5773.4

Thank you

[Patrick Kettner]

Thanks for confirming!