-
Notifications
You must be signed in to change notification settings - Fork 9.9k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
[Firefox regression] Fix disableRange=true
bug in PDFDataTransportStream
#10675
[Firefox regression] Fix disableRange=true
bug in PDFDataTransportStream
#10675
Conversation
1e449bc
to
9592e3e
Compare
Apparently I'm not really understanding the code well enough to fix this, since one of the existing unit-tests started failing now :-( Edit: I've also tested setting Lines 1496 to 1527 in 9b5a937
|
080ca42
to
89da03f
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Really good. Thank you for the patch.
Actually let me think more about this PR. As I recall, we cannot trust _contentLength. |
I spy pdf.js/src/core/chunked_stream.js Line 116 in 89da03f
|
Excellent point about So the current patch obviously won't cut it, as far as solutions go, but I'm wondering if a possible fix would be to dispatch a message (e.g. "progressiveComplete") from https://searchfox.org/mozilla-central/rev/56705678f5fc363be5e0237e1686f619b0d23009/browser/extensions/pdfjs/content/PdfStreamConverter.jsm#626-628 which is then passed to
Good find, that looks very much relevant here as well. Implementing something similar for |
89da03f
to
0f14872
Compare
The updated patch seems to work both with @yurydelendik Thanks for helping out here; does this look like a more viable approach to you? diff --git a/browser/extensions/pdfjs/content/PdfStreamConverter.jsm b/browser/extensions/pdfjs/content/PdfStreamConverter.jsm
--- a/browser/extensions/pdfjs/content/PdfStreamConverter.jsm
+++ b/browser/extensions/pdfjs/content/PdfStreamConverter.jsm
@@ -168,16 +168,19 @@ PdfDataListener.prototype = {
let writeOffset = 0;
while (this.buffers.length) {
let buffer = this.buffers.shift();
combinedArray.set(buffer, writeOffset);
writeOffset += buffer.length;
}
return combinedArray;
},
+ get isDone() {
+ return !!this.isDataReady;
+ },
finish: function PdfDataListener_finish() {
this.isDataReady = true;
if (this.oncompleteCallback) {
this.oncompleteCallback(this.readData());
}
},
error: function PdfDataListener_error(errorCode) {
this.errorCode = errorCode;
@@ -601,45 +604,53 @@ class RangedChromeActions extends Chrome
// requests, which we need to abort when we leave the page
domWindow.addEventListener("unload", function unload(e) {
domWindow.removeEventListener(e.type, unload);
self.abortLoading();
});
}
initPassiveLoading() {
- var data;
+ let data, done;
if (!this.streamingEnabled) {
this.originalRequest.cancel(Cr.NS_BINDING_ABORTED);
this.originalRequest = null;
data = this.dataListener.readData();
+ done = this.dataListener.isDone;
this.dataListener = null;
} else {
data = this.dataListener.readData();
+ done = this.dataListener.isDone;
this.dataListener.onprogress = (loaded, total) => {
this.domWindow.postMessage({
pdfjsLoadAction: "progressiveRead",
loaded,
total,
chunk: this.dataListener.readData(),
}, PDF_VIEWER_ORIGIN);
};
this.dataListener.oncomplete = () => {
+ if (!done && this.dataListener.isDone) {
+ this.domWindow.postMessage({
+ pdfjsLoadAction: "progressiveDone",
+ }, PDF_VIEWER_ORIGIN);
+ }
this.dataListener = null;
};
}
this.domWindow.postMessage({
pdfjsLoadAction: "supportsRangedLoading",
rangeEnabled: this.rangeEnabled,
streamingEnabled: this.streamingEnabled,
pdfUrl: this.pdfUrl,
length: this.contentLength,
data,
+ done,
}, PDF_VIEWER_ORIGIN);
return true;
}
requestDataRange(args) {
if (!this.rangeEnabled) {
return;
|
/botio unittest |
From: Bot.io (Windows)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.215.176.217:8877/51aec803513ac1b/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_unittest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/d6a084b392613fa/output.txt |
…Stream` Currently if trying to set `disableRange=true` in the built-in PDF Viewer in Firefox, either through `about:config` or via the URL hash, the PDF document will never load. It appears that this has been broken for a couple of years, without anyone noticing. Obviously it's not a good idea to set `disableRange=true`, however it seems that this bug affects the PDF Viewer in Firefox even with default settings: - In the case where `initialData` already contains the *entire* file, we're forced to dispatch a range request to re-fetch already available data just so that file loading may complete. - (In the case where the data arrives, via streaming, before being specifically requested through `requestDataRange`, we're also forced to re-fetch data unnecessarily.) *This part was removed, to reduce the scope/risk of the patch somewhat.* In the cases outlined above, we're having to re-fetch already available data thus potentially delaying loading/rendering of PDF files in Firefox (and wasting resources in the process).
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/d6a084b392613fa/output.txt Total script time: 2.86 mins
|
0f14872
to
bb384dd
Compare
From: Bot.io (Windows)SuccessFull output at http://54.215.176.217:8877/51aec803513ac1b/output.txt Total script time: 5.86 mins
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Approach is right. (The end goal was to have FirefoxCom match Streams API). Let's do it as you implemented for now. Thanks.
Have the changes in |
Ideally, they should probably land simultaneously with the changes being made here. Also, I'm no longer able to submit patches for |
It's also (usually?) possible for 2FA that you're presented with a secret key (I believe it's 16 characters) so that you can use, for example, Google Authenticator from a desktop. Refer to https://www.labnol.org/internet/google-authenticator-for-desktop/25341/ and https://github.com/grahammitchell/google-authenticator. Perhaps you already thought of such a solution though, but I thought I'd just mention it since it might help out with not needing an actual device. |
While that ought to work, and there's even e.g. a Firefox addon that could probably be used, doesn't it sort of negate the whole point of 2FA by using one and the same device though? |
Not necessarily. Two-factor authentication is nothing more than adding an additional step to the login process. It doesn't actually have to be another device, it should just be another type of data that someone else cannot obtain (easily). From https://en.wikipedia.org/wiki/Wikipedia:Simple_2FA: "You can use apps like WinAuth and KeeWeb to handle 2FA tokens on a desktop computer. This is the recommended way to use 2FA if you don't have a smartphone or tablet computer". I would highly recommend saving the 2FA secret in a password manager so it's properly encrypted. If your username/password would become public after a database breach, the 2FA token would still prevent people from logging in to your account. |
Looking at this again I don't believe that needs to happen first, since the only thing that will happen without the @timvandermeij Mind landing this to get the ball rolling; thanks! @rvandermeulen Could I please trouble you to include the following diff, https://gist.github.com/Snuffleupagus/960c70fe1775af04f8711f1699580a94, when the changes from this PR are uplifted to |
Sure thing! FWIW, I've been using https://bitbucket.org/kmaglione/hgext/src/default/phabricator.py on Windows rather than messing with arc and it works well. Feel free to drop me a line on email or IRC if you need help setting it up. |
/botio-linux preview |
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @timvandermeij received. Current queue size: 0 Live output at: http://54.67.70.0:8877/0c1279cc15b084e/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/0c1279cc15b084e/output.txt Total script time: 1.84 mins Published |
Thank you! |
Currently if trying to set
disableRange=true
in the built-in PDF Viewer in Firefox, either throughabout:config
or via the URL hash, the PDF document will never load. It appears that this has been broken for a couple of years, without anyone noticing.Obviously it's not a good idea to set
disableRange=true
, however it seems that this bug affects the PDF Viewer in Firefox even with default settings:initialData
already contains the entire file, we're forced to dispatch a range request to re-fetch already available data just so that file loading may complete.requestDataRange
, we're also forced to re-fetch data unnecessarily.) This part was removed, to reduce the scope/risk of the patch somewhat.In the cases outlined above, we're having to re-fetch already available data thus potentially delaying loading/rendering of PDF files in Firefox (and wasting resources in the process).
/cc @yurydelendik Could you please, time permitting of course, check that this patch makes sense?