Ensure that we don't try to re-open, or update the password-callback, when the password dialog is already open #15335
Conversation
|
I've tested this change and unfortunately it doesn't fix #15330
|
… when the password dialog is already open Currently in `disableWorker=true` mode it's possible that opening of password-protected PDF documents outright fails, if an *incorrect* password is entered. Apparently the event ordering is subtly different in the non-Worker case, which causes the password-callback to be updated *before* the dialog has been fully closed. To avoid that we'll utilize a `PromiseCapability` to keep track of the state of the password dialog, such that we can delay both re-opening and (importantly) updating of the password-callback until doing so is safe. This patch *may* also fix issue 15330, but it's impossible for me to tell.
Snuffleupagus
force-pushed
the
PasswordPrompt-activeCapability
branch
from
c16971c to
8984064
Compare
From: Bot.io (Linux m4)ReceivedCommand cmd_preview from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.241.84.105:8877/4c6a94f3ed926c3/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/4c6a94f3ed926c3/output.txt Total script time: 2.59 mins Published |
|
Is this PR ready for review, given the comments above that it doesn't seem to fix the original issue? I'm also fine with merging this if it's an improvement even if it doesn't yet fix the issue at hand, but if you're planning on looking further into this I'll wait with the review. |
Yes, since it fixes problems with
I'd prefer this landing as-is, after being tested and reviewed of course, since it fixes an existing issue where the My feeling is also that the remaining issue, which is difficult for me to debug, is connected to the dialog-polyfill itself somehow... [1] For reference, the correct password is "abc". |
|
Let's do this; thank you! |
Currently in
disableWorker=truemode it's possible that opening of password-protected PDF documents outright fails, if an incorrect password is entered. Apparently the event ordering is subtly different in the non-Worker case, which causes the password-callback to be updated before the dialog has been fully closed.To avoid that we'll utilize a
PromiseCapabilityto keep track of the state of the password dialog, such that we can delay both re-opening and (importantly) updating of the password-callback until doing so is safe.This patch may also fix issue #15330, but it's impossible for me to tell.