Revert commit fc73e2e (PR 5005) for breaking certain PDF files

[Snuffleupagus]

After fc73e2e (i.e. the second commit of PR #5005), the first page of http://arxiv.org/pdf/1112.0542v1.pdf no longer renders. This is only reproducible in the addon with range requests active.

/cc @fkaelberer

[Snuffleupagus]

/botio-windows preview

[pdfjsbot]

From: Bot.io (Windows)

---

Received

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

Live output at: http://107.22.172.223:8877/393c69973ee6b35/output.txt

[pdfjsbot]

From: Bot.io (Windows)

---

Success

Full output at http://107.22.172.223:8877/393c69973ee6b35/output.txt

Total script time: 0.86 mins

Published

• Viewer: http://107.22.172.223:8877/393c69973ee6b35/web/viewer.html
• B2G Viewer: http://107.22.172.223:8877/393c69973ee6b35/extensions/b2g/content/web/viewer.html
• Extension: http://107.22.172.223:8877/393c69973ee6b35/extensions/firefox/pdf.js.xpi
• Extension (AMO): http://107.22.172.223:8877/393c69973ee6b35/extensions/firefox/pdf.js.amo.xpi

[fkaelberer]

My apologies for the bug. The bytesToString method is not the problem here.
Instead, calling ChunkedStream.getBytes(limit) has different effects than successive calls of ChunkedStream.getByte(), and I honestly don't understand why.

The bug does not appear when using

var charBuf = [];
for (var n = 0; n < limit; ++n) {
  charBuf.push(stream.getByte());
}
var str = bytesToString(charBuf);

instead of

var str = bytesToString(stream.getBytes(limit));

in core.js.

Should I reopen a PR with the above fixes, or is it still too risky? (In particular, the changes in stream.js)

[Snuffleupagus]

Should I reopen a PR with the above fixes, or is it still too risky?

Personally I think we should try to figure out why this failed in the first place, before attempting to make any more changes.

My apologies for the bug.

We caught it just before the latest uplift to mozilla-central, so no harm done here :-)