-
Notifications
You must be signed in to change notification settings - Fork 10k
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
Fix the initialization/resetting of scripting-related events in the BaseViewer
#12853
Fix the initialization/resetting of scripting-related events in the BaseViewer
#12853
Conversation
…BaseViewer` The "pageopen"/"pageclose"-events are only necessary if, and only if, there's actually a sandbox to dispatch the events in. Hence we shouldn't dispatch those events unconditionally, as soon as `enableScripting` is set, but rather initialize that functionality only when needed. Furthermore, in `web/app.js`, there's currently a bug since we're attempting to *manually* simulate a "pageopen"-event for a page that may not actually have been rendered at the time. With the modified `BaseViewer.initializeScriptingEvents` method, we'll now dispatch a correct "pageopen"-event here.
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://3.101.106.178:8877/15d4f5f075ecdc5/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/d9d4170951b3e97/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/d9d4170951b3e97/output.txt Total script time: 2.97 mins
|
From: Bot.io (Windows)SuccessFull output at http://3.101.106.178:8877/15d4f5f075ecdc5/output.txt Total script time: 3.89 mins
|
…event in the `BaseViewer` Note first of all how the `PDFDocumentProxy.getJSActions` method in the API caches the result, which makes repeated lookups cheap enough to not really be an issue. Secondly, with the previous patch, we're now only dispatching "pageopen"/"pageclose"-events when there's actually a sandbox that listens for them. All-in-all, with these changes we can thus simplify the default-viewer "pageopen"-event handler a fair bit.
5216905
to
f1749f0
Compare
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://3.101.106.178:8877/5e92f3a83b19681/output.txt |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @Snuffleupagus received. Current queue size: 0 Live output at: http://54.67.70.0:8877/37aca4266180c5c/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.67.70.0:8877/37aca4266180c5c/output.txt Total script time: 3.02 mins
|
From: Bot.io (Windows)SuccessFull output at http://3.101.106.178:8877/5e92f3a83b19681/output.txt Total script time: 3.85 mins
|
Looks good! |
Now that (I assume) all viewer-code for the PageOpen/PageClose-scripting functionality have landed, I couldn't help seeing some potential for overall improvement here; note also that there's at least one bug related to the initialization.
Please refer to the individual commit messages for additional details.