[editor] Support disabling of editing when pdfjs.enablePermissions is set (issue 15049)
#15075
Conversation
Snuffleupagus
force-pushed
the
issue-15049
branch
from
fee1d4f
to
97408b8
Compare
…is set (issue 15049) For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the `pdfjs.enablePermissions` preference is set to `true` (since PDF document permissions could be seen as user hostile).[1] As I started looking at the issue, it soon became clear that *only* trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult. The following is an overview of the changes in this patch; sorry about the size/scope of this! - Use a new `AnnotationEditorUIManager`-instance *for each* PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next. - Re-factor the `BaseViewer.#initializePermissions`-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing). - When editing is enabled, let the Editor-buttons be `disabled` until the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions. - Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened. - Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.) - Enable editing by default in the development viewer, i.e. `gulp server`, since having to (repeatedly) do that manually becomes annoying after a while. - Finally, support disabling of editing when `pdfjs.enablePermissions` is set; fixes issue 15049. --- [1] Either manually with `about:config`, or using e.g. a [Group Policy](https://github.com/mozilla/policy-templates).
Snuffleupagus
force-pushed
the
issue-15049
branch
from
97408b8
to
35a6a50
Compare
|
/botio integrationtest |
1 similar comment
|
/botio integrationtest |
From: Bot.io (Linux m4)ReceivedCommand cmd_integrationtest from @calixteman received. Current queue size: 0 Live output at: http://54.241.84.105:8877/7c46917ec715871/output.txt |
From: Bot.io (Windows)ReceivedCommand cmd_integrationtest from @calixteman received. Current queue size: 0 Live output at: http://54.193.163.58:8877/99ef7c367842079/output.txt |
From: Bot.io (Linux m4)SuccessFull output at http://54.241.84.105:8877/7c46917ec715871/output.txt Total script time: 4.53 mins
|
From: Bot.io (Windows)FailedFull output at http://54.193.163.58:8877/99ef7c367842079/output.txt Total script time: 7.28 mins
|
|
I tested the patch locally with |
Strange, it works for me... Can you try a skip-cache reload of the viewer, to ensure that the old button state isn't being kept somehow? |
|
It works with an hard refresh. |
For encrypted PDF documents without the required permissions set, this patch adds support for disabling of Annotation-editing. However, please note that it also requires that the
pdfjs.enablePermissionspreference is set totrue(since PDF document permissions could be seen as user hostile).[1]As I started looking at the issue, it soon became clear that only trying to fix the issue without slightly re-factor the surrounding code would be somewhat difficult.
The following is an overview of the changes in this patch; sorry about the size/scope of this!
Use a new
AnnotationEditorUIManager-instance for each PDF document opened in the GENERIC viewer, to prevent user-added Annotations from "leaking" from one document into the next.Re-factor the
BaseViewer.#initializePermissions-method, to simplify handling of temporarily disabled modes (e.g. for both Annotation-rendering and Annotation-editing).When editing is enabled, let the Editor-buttons be
disableduntil the document has loaded. This way we avoid the buttons becoming clickable temporarily, for PDF documents that use permissions.Slightly re-factor how the Editor-buttons are shown/hidden in the viewer, and reset the toolbar-state when a new PDF document is opened.
Flip the order of the Editor-buttons and the pre-exising toolbarButtons in the "toolbarViewerRight"-div. (To help reduce the size, a little bit, for the PR that adds new Editor-toolbars.)
Enable editing by default in the development viewer, i.e.
gulp server, since having to (repeatedly) do that manually becomes annoying after a while.Finally, support disabling of editing when
pdfjs.enablePermissionsis set; fixes issue Disable editing when the pdf disallows it #15049.[1] Either manually with
about:config, or using e.g. a Group Policy.