Correctly validate the response status for non-HTTP fetch requests (PR 8768 follow-up)

[Snuffleupagus]

It seems that the status check, for non-HTTP loads, has been inverted which causes the default viewer to refuse to open local PDF files. Follow-up to PR #8768.

STR:

1. Make sure that fetch support is enabled in the browser. In Firefox Nightly, set dom.streams.enabled = true and javascript.options.streams = true in about:config. Edit: Just to clarify, please note that the issue is reproducible in Google Chrome too.
2. Open https://mozilla.github.io/pdf.js/web/viewer.html.
3. Click on the "Open file" button, and open a new PDF file.

ER:
A new PDF file should open in the viewer.

AR:
The PDF file fails to open, with an error message of the following format:
Message: Unexpected server response (200) while retrieving PDF "blob:https://mozilla.github.io/a4fc455f-bc05-45b5-b6aa-2ecff3cb45ce".

Edit: Fixes #8870.

[yurydelendik]

Let's remove entire if(!isHttp) statement. Not sure if fetch() for file: protocol is returning 0 for success.

[Snuffleupagus]

Let's remove entire if(!isHttp) statement.

Fixed now, thanks!

Not sure if fetch() for file: protocol is returning 0 for success.

According to https://fetch.spec.whatwg.org/#scheme-fetch, it would seem that file:// support isn't even properly defined in the specification.

[Snuffleupagus]

/botio-linux preview

[pdfjsbot]

From: Bot.io (Linux m4)

---

Received

Command cmd_preview from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/491b20fe9aed89e/output.txt

[pdfjsbot]

From: Bot.io (Linux m4)

---

Success

Full output at http://54.67.70.0:8877/491b20fe9aed89e/output.txt

Total script time: 2.32 mins

Published

• Viewer: http://54.67.70.0:8877/491b20fe9aed89e/web/viewer.html
• Extension: http://54.67.70.0:8877/491b20fe9aed89e/extensions/firefox/pdf.js.xpi

[pdfjsbot]

From: Bot.io (Linux m4)

---

Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.67.70.0:8877/faf8c29db700c60/output.txt

[pdfjsbot]

From: Bot.io (Windows)

---

Received

Command cmd_test from @Snuffleupagus received. Current queue size: 0

Live output at: http://54.215.176.217:8877/4016277e2bbd6d7/output.txt

[pdfjsbot]

From: Bot.io (Windows)

---

Failed

Full output at http://54.215.176.217:8877/4016277e2bbd6d7/output.txt

Total script time: 29.66 mins

• Font tests: Passed
• Unit tests: Passed
• Regression tests: FAILED

Image differences available at: http://54.215.176.217:8877/4016277e2bbd6d7/reftest-analyzer.html#web=eq.log

[pdfjsbot]

From: Bot.io (Linux m4)

---

Failed

Full output at http://54.67.70.0:8877/faf8c29db700c60/output.txt

Total script time: 60.00 mins

[yurydelendik]

/botio-linux test

[pdfjsbot]

From: Bot.io (Linux m4)

---

Received

Command cmd_test from @yurydelendik received. Current queue size: 0

Live output at: http://54.67.70.0:8877/4b687477818032a/output.txt

[pdfjsbot]

From: Bot.io (Linux m4)

---

Success

Full output at http://54.67.70.0:8877/4b687477818032a/output.txt

Total script time: 16.44 mins

• Font tests: Passed
• Unit tests: Passed
• Regression tests: Passed

[yurydelendik]

Thank you for the patch.

[mukulmishra18]

According to https://fetch.spec.whatwg.org/#scheme-fetch, it would seem that file:// support isn't even properly defined in the specification.

file: protocol is not supported by the native fetch implementation and always throws TypeError, see JakeChampion/fetch#186 .