1495204 - [pdf.js] Lots of errors "system principal mismatch" with privacy.firstparty.isolate=true

Status: NEW

(Firefox :: PDF Viewer, defect, P5)

Description

[Franck (Wip)]

Mozilla/5.0 (Windows NT 6.1; Win64; x64; rv:62.0) Gecko/20100101 Firefox/62.0
Build ID: 20180920131237

Steps to reproduce:
  - open about:config and set privacy.firstparty.isolate=true
  - open the browser console (Ctrl-Shift-J) and clear it
  - open a PDF document using the internal pdf.js viewer
    e.g. https://dlcdnets.asus.com/pub/ASUS/mb/LGA1151/MAXIMUS_VIII_RANGER/G10485_MAXIMUS_VIII_RANGER_UM_WEB.pdf
  - watch the console while the PDF is loading

Actual results:
  the browser console shows lots of errors of the like 'Attempting to post a message to window with url
  "resource://pdf.js/web/viewer.html" and origin "resource://pdf.js^firstPartyDomain=asus.com" from a
  system principal scope with mismatched origin "[System Principal]".'

Expected results:
  there should be no such errors

With the example PDF given at the STR, the errors count goes up to several thousands.
However, it does not seems to impact the rendering of the document.

Note: I still can see these errors with the Nightly build of 2018-09-28.

Comment 1

[Ethan Tseng [:ethan]]

I am using Firefox Nightly 65.0a1 on macOS and couldn't reproduce these error messages.
Perhaps this only happens on Windows?
Franck, which OS are you using?

Comment 2

[Tom Ritter [:tjr]]

I reproduced this on Mac just last night by sheer accident going to https://ritter.vg/p/tor-v1.6.pdf

Comment 3

[Simon Mainey]

(In reply to Tom Ritter [:tjr] from comment #2)
> I reproduced this on Mac just last night by sheer accident going to
> https://ritter.vg/p/tor-v1.6.pdf

reproduced using on Windows (FF63)

Comment 4

[Ethan Tseng [:ethan]]

Weird. Seems I am the only one who cannot reproduce it.

Tim, could you help to look into the root cause of these error messages?

Comment 5

[Tim Huang[:timhuang]]

This message comes from here [1]. To me, it's more like a warning rather than an error because of things will still process.

The reason why the OA is mismatched is that the pdf.js wants to post a message to content from a system-privileged script. And the system principal won't have an OA so it mismatches with the OA of content, which has a firstPartyDomain in its OA.

And this occurs not only with FPI but with every OA which is not a default one. I can reproduce this with Container as well.

So far, I don't have a good solution for this. Maybe we need a special postMessage for chrome code where we can specify an OA when posting messages from system principal. However, we still need to patch pdf.js even with this API. Or maybe we can just make the message to be not an error.

What do you think, baku?


[1] https://searchfox.org/mozilla-central/rev/39cb1e96cf97713c444c5a0404d4f84627aee85d/dom/base/nsGlobalWindowOuter.cpp#5773-5782

Comment 6

[Andrea Marchesini [:baku]]

https://searchfox.org/mozilla-central/rev/39cb1e96cf97713c444c5a0404d4f84627aee85d/dom/base/nsGlobalWindowOuter.cpp#5759
This will be always wrong for non-default OriginAttributes.

Wondering if we can simply remove that warning message. It doesn't seem particularly useful: that code writes a warning message just when OriginAttributes do not match, but no warnings when OriginAttributes match. Why? Maybe it's more useful to have warning messages when SystemPrincipal talks with content windows...

Comment 7

[Simon Mainey]

update: issue still present in release 81, dev 82, beta 82. Nightly 83 doesn't report the errors (but this is probably a symptom of bug 1670942, not any "fix")