Implement Fetch API for streaming PDF loads on Chrome

[jordan-thoms]

Chrome has now shipped the Fetch API ( https://groups.google.com/a/chromium.org/forum/#!topic/blink-dev/35_QSL1ABTY ) in Chrome 43. I'm not sure yet if other browser vendors will implement it, but seeing as PDF.js has support for the firefox-only moz-chunk-arraybuffer, it seems reasonable to implement this for Chrome. We often see poor network performance loading PDFs, especially when using range requests, and hopefully this can help.

I'm planning to start working on this over the next few days, any initial thoughts?

[jordan-thoms]

Actually to correct that, seems it's already implemented in Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=1039846

[Snuffleupagus]

Is this perhaps a duplicate of issue #5319?

[jordan-thoms]

Yes I guess so. It appears that it's also possible to do streaming through the normal XHR api, so I'll try that first since it will most likely require less code changes.

EDIT: Actually, seems there are substantial advantages to doing this through the Fetch API so that seems preferable.

[timvandermeij]

See #6348 for additional information. If someone is willing to work on this, feel free to submit a pull request. We must be sure to remain compatible for old browsers, so we probably need a fallback to XHR or a polyfill for fetch() to do so.

[nschloe]

FYI, GitHub published a fetch polyfill.

[yurydelendik]

Our main use case is progressive fetching portions of the remote file. The solution using Fetch API shall not regress our streaming and range fetching capabilities.

[yurydelendik]

We use sync-XHR in l10n and cmap components. We shall probably create (blocking?) issues to migrate both to async-XHR/fetch as well.

[Rob--W]

@yurydelendik I patched l10n to not use sync XHR a while back (#5739), so only cmaps and fonts need to be fixed.

Note that fetch is not yet usable as a full replacement for XHR, because:

• Chrome: Permissions whitelists (e.g. extension permissions, or --disable-web-security flag) does not propagate to the fetch API https://crbug.com/478345 (fixed as of 45.0.2402.0).
• Chrome: Anything other than http: and https: is ignored, including blob:, data:, file:, filesystem: and ftp: URLs. https://crbug.com/455109 (no fix yet)
• Design flaw: fetch requests cannot be cancelled (like XHR's abort). There is no resolution yet, the discussion seems to have stalled due to bikeshedding (Aborting a fetch whatwg/fetch#27)
• Firefox: fetch requests are not aborted upon unload: https://bugzil.la/1165237
• Limitations of polyfills: fetch cannot be implemented in terms of XHR (fetch is way more powerful), and XHR cannot be implemented in terms of fetch (e.g. missing .abort()). We should try to get the best of both APIs, and not add an incomplete polyfill that is only an incomplete shim of both APIs).

In theory, fetch supersedes XMLHttpRequest, and fetch would replace XHR, but in practice that's not possible yet. fetch's only advantage over XHR (from PDF.js's perspective) is streaming response bodies. Given the above limitations, if we want to use fetch, we still have to keep the XHR implementation in the core.

And, note that fetch support does not imply support for readable body streams. Chrome supported fetch since 42, but streams were only supported since 43.

[yurydelendik]

Thanks, @Rob--W

Filed #6352 for async cmaps