No usable progress bar when using fetch stream

[Rob--W]

STR:

1. Open the latest version of the PDF.js Chrome extension (v2.0.301) - https://chrome.google.com/webstore/detail/pdf-viewer/oemmndcbldboiebfnladdacbdfmadadm
2. Visit https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf
3. To simulate the behavior of the previous published version of the extension, open the debugger and put a breakpoint at the start of content/build/pdf.js (in the main thread) and refresh the page. When the breakpoint is hit, run Response = undefined; to disable fetch and fall back to XHR.

Result:

• After step 2, the progress bar is in an indeterminate state.
• After step 3, the progress bar grows as expected.

In both cases the Content-Length response header is present, so I would expect a meaningful progress bar.

[Snuffleupagus]

It seems that this may be related to, or even a duplicate of, issue #9103.

[Rob--W]

I pinned this bug down to the following:

fetch makes a CORS request by default, so that the response is of type cors instead of basic. Consequently, many headers are not exposed to the JS code. "type" is elaborated here: https://developer.mozilla.org/en-US/docs/Web/API/Response/type

To see the difference, run the following snippet from the console, first in the extension, and then from https://www.adobe.com/favicon.ico (same-origin):

fetch('https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf', {mode:'cors'})
.then(res=>console.log(res, Array.from(res.headers).map(v=>v.join(': ')).join('\n')))

When run from chrome-extension://oemmndcbldboiebfnladdacbdfmadadm/https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf

Response {type: "cors", url: "https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf", redirected: false, status: 200, ok: true, …}
cache-control: max-age=21600
content-type: application/pdf
expires: Tue, 06 Feb 2018 18:29:38 GMT
last-modified: Tue, 06 Feb 2018 01:54:38 GMT

When run from https://www.adobe.com/favicon.ico

Response {type: "basic", url: "https://www.adobe.com/content/dam/acom/en/devnet/acrobat/pdfs/pdf_reference_1-7.pdf", redirected: false, status: 200, ok: true, …}
accept-ranges: bytes
cache-control: max-age=21600
connection: keep-alive
content-length: 55779577
content-type: application/pdf
date: Tue, 06 Feb 2018 12:28:57 GMT
etag: "35320f9-5648176131fc9"
expires: Tue, 06 Feb 2018 18:28:57 GMT
last-modified: Tue, 06 Feb 2018 01:54:38 GMT
server: Apache
strict-transport-security: max-age=900
x-adobe-content: AEM,acom
x-adobe-loc: ew1
x-content-type-options: nosniff
x-frame-options: SAMEORIGIN

Ideally, the fetch API should be called with {mode: 'same-origin'} from the extension, but that seems to be blocked by Chrome.

The next possible things to try is to expose the headers by using the webRequest extension API to augment the Access-Control-Expose-Headers response header.

Or, use the webRequest API to extract these header values directly, by adding a temporary listener for the webRequest.onHeadersReceived event, or via the initial request. I did something in the past for PDF streams on ChromeOS (#4229), perhaps the same logic can also be applied to fetch streams?

(Just thinking out aloud)

[Rob--W]

This is the bug for exposing "headers" in fetch to extensions:
https://bugs.chromium.org/p/chromium/issues/detail?id=784528