1260961 - PDF.js doesn't work with cross-origin environment, because worker no longer throws on Firefox 45+ and onerror handler is missing

Status: RESOLVED FIXED

(Web Compatibility :: Site Reports, defect)

Description

[Nhan Dang]

Attachment: CORS error on Browser Console

User Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10_11_2) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/48.0.2564.97 Safari/537.36

Steps to reproduce:

Open a sample page at https://ecosystem.atlassian.net/wiki/pages/viewpage.action?spaceKey=CONF&title=Confluence+Connect+Week+Kickoff+Slides
Click on the thumbnail of the PDF file.
Wait for the PDF file to be ready.


Actual results:

The spinner keeps running ... forever. There was an CORS error on Browser Console. You can find screenshots attached.



Expected results:

The spinner runs for 1-2 seconds then the PDF file is displayed

Comment 1

[Nhan Dang]

Attachment: Spinner keeps running

Comment 2

[Nhan Dang]

I tested this page with few major browsers and older version of Firefox. Worked fine on Chrome, Safari and Firefox 44.0.2. This seems to happen since 45. That cross-site script is loaded successfully by Firefox 44.0.2 (screenshot attached)

Comment 3

[Nhan Dang]

Attachment: Working fine on FF 44.0.2

Comment 4

[Kohei Yoshino [:kohei]]

Looks like the URL requires sign-in. Do you have any public URL we can test?

Comment 5

[Nhan Dang]

Thanks Kohei. That is actually a public site. You can sign up for a free account fairly easy there:
https://ecosystem.atlassian.net/admin/users/sign-up

Let me know if you need something else.

Comment 6

[Kohei Yoshino [:kohei]]

This is probably a duplicate of Bug 1260388. Will create an account to test. Thanks.

Comment 7

[Kohei Yoshino [:kohei]]

Regression range: https://hg.mozilla.org/integration/mozilla-inbound/pushloghtml?fromchange=7d5a2743cc47f60e08dcd115e10f0130862eb5df&tochange=6c6b3811aeb7472cb0de572ce1a456d07756be9a

Culprit: Bug 1218433

The reporter of Bug 1260961 says his PDF.js installation doesn't work in Chrome as well, but this bug's URL works in Chrome, so these might be different cases.

[Tracking Requested - why for this release]: New site compatibility regression in Firefox 45.

Comment 8

[Kohei Yoshino [:kohei]]

I meant: The reporter of Bug 1260388 says...

Comment 9

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

This doesn't look like a CORS error. But we're definitely blocking a script load.

Comment 10

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Is this about loading a <script>, or about loading a Worker?

Comment 11

[Andrea Marchesini [:baku]]

Jonas is taking care of this issue. Removing the NI.

Comment 12

[Liz Henry (:lizzard) (relman/hg->git project)]

Tracking, recent regression.

Comment 13

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Andrea, it was not my intent to take this bug. I was only trying to help along since I was the reviewer of the bug that caused this.

Comment 14

[Kohei Yoshino [:kohei]]

They are using PDF.js 1.1.469. The main script and worker script are on the same origin:

https://d2p4ir3ro0j0cb.cloudfront.net/ecosystem.atlassian.net/wiki/s/6c0981174e94142364564819dc0d1413-CDN/en_GB/6437/4f3a11a8e79855052f86fe30466d81ee677d8ec4/2.1.5/_/download/batch/com.atlassian.confluence.plugins.confluence-previews:confluence-previews-pdf/com.atlassian.confluence.plugins.confluence-previews:confluence-previews-pdf.js?locale=en-GB

https://d2p4ir3ro0j0cb.cloudfront.net/ecosystem.atlassian.net/wiki/s/d41d8cd98f00b204e9800998ecf8427e-CDN/en_GB/6437/4f3a11a8e79855052f86fe30466d81ee677d8ec4/2.1.5/_/download/batch/com.atlassian.confluence.plugins.confluence-previews:confluence-previews-pdf-worker/com.atlassian.confluence.plugins.confluence-previews:confluence-previews-pdf-worker.js

Comment 15

[Kohei Yoshino [:kohei]]

Also <iframe> is not used in this case, unlike Bug 1260388. The PDF preview is directly added to the page.

Comment 16

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Andrea: I propose that we back out bug 1218433 until someone figures out what's going wrong here.

Comment 17

[Kohei Yoshino [:kohei]]

Parent document: https://ecosystem.atlassian.net
Parent script: https://d2p4ir3ro0j0cb.cloudfront.net
Worker script: https://d2p4ir3ro0j0cb.cloudfront.net

What's the same-origin policy for Workers btw? Should it share the same origin as the parent document, or the parent script? I was thinking of the latter. If the former is correct, worker scripts cannot be served from a CDN like this case.

Comment 18

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I'm not sure what you mean by "parent" document? "parent" generally refers window.parent. I.e. to the page that contained an <iframe>.

Say that a HTML page at url A contains a <iframe src="B">.
And the HTML page at B contains <script src="C">.
And the JS script at C contains |new Worker(D)|.

In that case B needs to be same-origin with D. If it is not the worker should not be executed. It does not matter what the URL of A or C is.

I feel pretty confident that this restriction was enforced before bug 1218433 landed. I also feel confident that other browsers have the same restriction.

Generally speaking, the URL of a <script> never matters. Once a script is executed in the context of a HTML page, only the origin of the HTML page matters. We don't track which function call comes from which <script>, we just track which page it executes inside of.

Comment 19

[Kohei Yoshino [:kohei]]

Hmm, then this bug is perhaps due the fact that the worker script is at https://d2p4ir3ro0j0cb.cloudfront.net, not at https://ecosystem.atlassian.net ? But this was working until Firefox 44 and still working in Chrome at least.

Comment 20

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Like I said, I feel very confident that if the HTML page URL and the worker URL are not same-origin that Firefox 44 blocked the load. As do other browsers. We've had mochitests that check for that for a long time.

Comment 21

[Kohei Yoshino [:kohei]]

Attachment: Screenshot on Firefox 44.0.2

I just double checked with Firefox 44.0.2 and the reported URL was working. I don't understand much about the change in Bug 1218433, but my guess is Firefox 45+ no longer honours CORS set for the worker script, as originally reported?

> Access-Control-Allow-Origin: https://ecosystem.atlassian.net

Comment 22

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Are you sure that that's loading a Worker and not a <script>? 

Here are all the CORS errors. Note that they all contain the string "CORS", so I don't think that there's anything CORS related here.

http://mxr.mozilla.org/mozilla-central/source/dom/locales/en-US/chrome/security/security.properties#8

Comment 23

[Kohei Yoshino [:kohei]]

If their confluence-previews-pdf.js is working as expected, it's just calling |new Worker|.

I cannot read C++ but... the patch removed GetContentPolicy() and NS_ERROR_CONTENT_BLOCKED so the new code is not checking the worker's CORS and won't raise a CORS error even if blocked, maybe?

https://bugzilla.mozilla.org/attachment.cgi?id=8686093&action=diff#a/dom/workers/ScriptLoader.cpp_sec2

Comment 24

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

I don't know what's happening. We clearly need someone to step through the C++ code. I recommend backing out until we've done that.

Comment 25

[Kohei Yoshino [:kohei]]

(In reply to Kohei Yoshino [:kohei] from comment #23)
> If their confluence-previews-pdf.js is working as expected, it's just
> calling |new Worker|.

Looks like I was wrong here. Here's my analysis:

On Firefox 44, PDF.js is loading the worker using a <script> because this |new Worker| is throwing in this try-catch:

https://github.com/mozilla/pdf.js/blob/master/src/display/api.js#L1290-L1374

and the fallback function is used:

https://github.com/mozilla/pdf.js/blob/master/src/shared/util.js#L871-L884

I can see this in the <head> of the HTML:

<script src="//d2p4ir3ro0j0cb.cloudfront.net/ecosystem.atlassian.net/wiki/s/d41d8cd98f00b204e9800998ecf8427e-CDN/en_GB/6437/4f3a11a8e79855052f86fe30466d81ee677d8ec4/2.1.5/_/download/batch/com.atlassian.confluence.plugins.confluence-previews:confluence-previews-pdf-worker/com.atlassian.confluence.plugins.confluence-previews:confluence-previews-pdf-worker.js"></script>

However, Firefox 45 now longer throws a SecurityError as reported in Bug 1241888, this fallback function doesn't get called and therefore the PDF file will never be loaded.

Comment 26

[Kohei Yoshino [:kohei]]

So the possible solution is:

1. Back out Bug 1218433
2. Add worker.onerror to PDF.js as suggested in Bug 1260388
3. Encourage Atlassian to update their PDF.js copy
4. Fix Bug 1218433 again

Comment 27

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

Kohei: Thanks! That explains things perfectly. I forgot that we changed workers from throwing to firing onerror.


I don't have an opinion about if this broke enough stuff that we should back out the patch, or if we should just evangelize. Might definitely be safer to back out for now and figure out a plan.

Comment 28

[Kohei Yoshino [:kohei]]

Posted the site compatibility doc: https://www.fxsitecompat.com/en-CA/docs/2016/loading-cross-origin-worker-no-longer-throws-worker-in-sandboxed-iframe-will-fail/

Comment 29

[Yury Delendik (:yury)]

PDF.js v1.4.187+ has worker load error detection now. See https://github.com/mozilla/pdf.js/pull/7107

Comment 30

[Kohei Yoshino [:kohei]]

Nhan: Please let your WebDev team know about this issue. Once the site is updated with a newer version of PDF.js available from https://github.com/mozilla/pdfjs-dist, the issue should be solved.

Comment 31

[Kohei Yoshino [:kohei]]

Now backing out of Bug 1218433 might not be necessary as PDF.js has already been patched. Even if this cross-origin change has broken other libraries and sites as well, fixing the issue should be easy given the site compatibility doc.

I'll keep the dev-doc-needed keyword in case MDN folks would also like to document this.

Comment 32

[Jonas Sicking (:sicking) No longer reading bugmail consistently]

If we see more regressions than PDF.js we should probably back out. Evangelism takes time and it's not good to regress users.

But sounds like we can keep the code landed for now.

Comment 33

[Nhan Dang]

I'll ask our Media team to upgrade PDF.js. Thanks much all for pointing out the root cause.

Comment 34

[Kohei Yoshino [:kohei]]

Thank you. Since we haven't seen any other bug reports, it would be safe to untrack and move this over Evangelism.

Comment 35

[Mike Taylor [:miketaylr]]

It looks like Atlassian is aware of the need to update (in Comment #33), so I guess we can leave this open until that happens.

Comment 36

[Daniel Veditz [:dveditz] back January 5, 2026]

Site needs to upgrade, don't need to track it as a fix for Firefox releases

Comment 37

[Mike Taylor [:miketaylr]]

Nhan, the linked URL requires auth now, do you know if this was ever fixed? Thanks.

Comment 38

[Nhan Dang]

It was fixed by a PDF.js bump.

Thanks,
Nhan

Comment 39

[Mike Taylor [:miketaylr]]

Thanks!

Comment 40

[Chris Mills [:cmills]]

Note to whoever ends up updating MDN — Kohei's note in https://bugzilla.mozilla.org/show_bug.cgi?id=1260961#c28 explains this perfectly.

Comment 41

[Chris Mills [:cmills]]

I've documented this by adding a note to 

https://developer.mozilla.org/en-US/docs/Web/API/Worker
https://developer.mozilla.org/en-US/docs/Web/API/AbstractWorker/onerror