Hey Browser Devs,
Flew into Austin yesterday for the Y'all Hands.
This past week I've been investigating the root cause of #17933 and #15599 (pdf loads going to the default circuit rather than the first party domain). Technically speaking #17933 is now no-repro as it dealt specifically with the download button which now doesn't make any network requests.
As explained in the comments of #15599 the default circuit is being used by XMLHttpRequests made by pdf.worker.js. The offending requests occur in the context of a Web Worker. For some reason, requests created in the context of the Worker inherit the global default nsIPrincipal (which the first party domain is derived from) which has an empty first party domain (which ultimately forces use of the --unknown-- circuit)
I've verified that requests from the pdf.js 'foreground' (?) context is associated with the correct circuit. My preliminary reading suggests that there is a one-to-one mapping of Web Workers to Tabs (ie there's no sharing between tabs, unlike with Shared Workers or Service Workers) so there doesn't seem to be any web-standards reason why pdf.worker.js 'context' shouldn't share a nsIPrincipal with the calling pdf.js 'context.'
My next line of inquiry is to learn about/investigate of nsIPrincipal's work and determine whether we can fix Workers to inherit their caller's nsIPrincipal. I would imagine there's some thread-safety considerations to be made here, since Workers allow for background concurrent js. Need to see if in practice the get their own thread or if they operate on the same thread as the js 'UI' thread.
best, -Richard