Open Bug 1495204 Opened 11 months ago Updated 9 months ago

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

Categories

(Firefox :: PDF Viewer, defect, P3)

62 Branch
x86_64
Windows 7
defect

Tracking

()

People

(Reporter: wip.the.gruik, Unassigned)

References

(Blocks 1 open bug)

Details

(Whiteboard: [tor])

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.
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?
Flags: needinfo?(wip.the.gruik)
Whiteboard: [tor]
I reproduced this on Mac just last night by sheer accident going to https://ritter.vg/p/tor-v1.6.pdf
(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)
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?
Flags: needinfo?(tihuang)
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
Flags: needinfo?(tihuang) → needinfo?(amarchesini)
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...
Flags: needinfo?(amarchesini)
Flags: needinfo?(wip.the.gruik)
Status: UNCONFIRMED → NEW
Ever confirmed: true
Priority: -- → P3
You need to log in before you can comment on or make changes to this bug.