Closed Bug 1565672 Opened 4 years ago Closed 4 years ago

A local opened web-worker seems not to work anymore with Firefox 68.0


(Core :: DOM: Security, defect, P3)

68 Branch





(Reporter: bozle, Unassigned)




(Keywords: regression, Whiteboard: [domsecurity-backlog3])


(2 files)

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

Steps to reproduce:

I LOCALLY tried to run the web-worker example from It does work with Firefox 60.8.0esr. But it does not work anymore with Firefox 68.0. If I run the example ONLINE ( it does work with Firefox 68.0.

Actual results:

It seems that JavaScript can open the web-worker and sends messages to it. But the web-worker does not answer and I can not see any errors.

Expected results:

In the example, the web-worker should multiply two numbers and should send back the result.

Hi Bozle,

Could you be a little more specific on how to run the web-worker example locally, please? Because I've downloaded the files from, saved them in a folder, opened index.html on firefox release v67, I enter two numbers to be multiplied and it does not work. Taking into account what you said, that version should've worked. Maybe I'm missing a step. If you have a video, that's always welcomed.

Thanks in advance, Flor.

Flags: needinfo?(bozle)

Hi Florencia. I will give you more information soon. But please give me some days :-). Kind regards, Peter (real name :-) )

Flags: needinfo?(bozle)

ok, no hurry :)

Blocks: file-fallout
Component: Untriaged → DOM: Security
Ever confirmed: true
Keywords: regression
Product: Firefox → Core
Regressed by: CVE-2019-11730

Although this is a "regression" in Firefox, this aligns our behavior with other browsers. Most developers of sites complex enough to need workers can easily set up a simple python or node localhost web server to run their tests.

Priority: -- → P3
Whiteboard: [domsecurity-backlog3]

On the other hand see bug 1570629 comment 4 -- we may fix both of these

Here a video to visualize the problem. I hope it helps.

(In reply to Daniel Veditz [:dveditz] from comment #4)

Although this is a "regression" in Firefox, this aligns our behavior with other browsers. Most developers of sites complex enough to need workers can easily set up a simple python or node localhost web server to run their tests.

Hi Daniel V. Did I understood it right? Because in the past it was possible for malicious code to read out local stored files (1), firefox has tightened up the same-origin policy (2). And other browsers already behave the same way or will behave the same way in the future (3).
Ist my interpretation correct?
(3) But it still works in the Microsoft Edge 44.17763.1.0
Best regards, Peter

(In reply to bozle from comment #7)

Did I understood it right?

Yup, you understood it correctly.

(In reply to Mark Straver from comment #8)
Hi Mark. Thank you for your answer. Then I will close this incident as 'invalid' because it is not a bug.

Closed: 4 years ago
Resolution: --- → INVALID

Hello together

Please excuse me for coming back to this point. But when I read the following article, I again came to the conclusion that it should work.

Or am I wrong. I guess I do :-) but I do not understand it anymore.

Kind regards Peter

Resolution: INVALID → ---

By the way, it works if I deactivate the setting mentioned in the article ( > about:config > security.fileuri.strict_origin_policy). That would be a Plan B but I still have got the hope, that it should be possible.

That document is very out of date and is not maintained; hence the red border and "Archive" in the URL. The current designed behavior is that workers loaded from file:// should not work, basically, unless you load the worker from the exact same file as the HTML involved.

Setting security.fileuri.strict_origin_policy to false is a really bad idea. It leads to a behavior that is extremely insecure.

If you want to go back to the (slightly, not extremely) insecure behavior in Firefox 67, you probably want to look at the privacy.file_unique_origin pref.

(In reply to Boris Zbarsky [:bzbarsky, bz on IRC] from comment #12)
Thank you for your answer. I was so focused finding a solution for my problem that i didn't see that the document is out of date :-). Security - of course - is important to me and therefore I follow your advice and won't change this setting it to false (security.fileuri.strict_origin_policy). I have found a solution on the internet ( I will close this incident again.

Just for the case that someone is struggling with the same situation. Here, a short example how to create a worker without loading a file:

'use strict';
var mod = function(){
		workerData = new Blob(
			['var i = 0; setInterval(function(){i++; postMessage(i);},500);'], {type: "text/javascript"}

		init = function(){
				myWorker = new Worker(

			myWorker.onmessage = function(e){

		init : init
Closed: 4 years ago4 years ago
Resolution: --- → INVALID
Has Regression Range: --- → yes
You need to log in before you can comment on or make changes to this bug.