WebViewer Version:12.0.1
Do you have an issue with a specific file(s)?
The popup “Edit” behavior reproduces on any PDF with editable text. The follow-on
Content Edit crash on confirming delete is document-specific — we have a file that
reproduces it and can share it privately.
Can you reproduce using one of our samples or online demos?
Yes — the popup Edit vs double-click behavior reproduces on the WebViewer Content
Edit / “Edit Text” demo with any editable PDF.
Are you using the WebViewer server?
No (client-side only).
Does the issue only happen on certain browsers?
No — reproduced on Chrome (latest) on Windows 11; not browser-specific.
Is your issue related to a front-end framework?
We use React, but the issue is in WebViewer’s own UI handler, not our framework
integration.
Is your issue related to annotations?
It involves content-edit placeholder annotations (isContentEditPlaceholder), via
the annotation popup.
Please give a brief summary of your issue:
Content Edit: annotation popup “Edit” does not activate the box editor like a
double-click, so keyboard edits fall through to delete.
Please describe your issue and provide steps to reproduce it:
For a content-edit text placeholder, entering edit mode via the annotation popup
“Edit” button (data-element “annotationContentEditButton”) does not behave the
same as a physical double-click. The popup Edit enters edit mode but does not
place the text caret / fully activate the Content Box editor, so Backspace/Delete
are treated as “delete the selected placeholder” instead of editing characters.
Steps to reproduce:
- Load a PDF with editable text and enable Content Edit:
instance.UI.enableFeatures([instance.UI.Feature.ContentEdit]); - Single-click a content-edit box so the annotation popup appears.
- Click the popup “Edit” button.
- Press Backspace or Delete.
Expected: same as double-clicking the box — the caret is in the text and
Backspace/Delete edit characters.
Actual: the caret is not placed; Backspace/Delete do not edit characters and are
handled as a placeholder-delete action (which triggers the “Delete Content”
confirmation). Double-clicking the same box works correctly.
Relevant WebViewer UI code:
onEditContent = () => {
annotManager.trigger(‘annotationDoubleClicked’, focusedAnnotation);
dispatch(actions.closeElement(‘annotationPopup’));
};
The synthetic ‘annotationDoubleClicked’ does not place the caret the way a real
double-click does.
Additional, document-specific observation:
On some documents, confirming the “Delete Content” modal (via the popup Delete
button, or via the keyboard path above) throws inside the compiled core and
leaves Content Edit broken (further edits no-op until reload). Observed errors
originate in webviewer-core.min.js, e.g.:
- TypeError: Cannot read properties of undefined (reading ‘innerHTML’) in parseCopyText
- TypeError: Cannot read properties of null (reading ‘getViewerCoordinates’) in fireEventTextAdded
- TypeError: Cannot read properties of null (reading ‘insertPages’)
Questions:
- Is there a supported API to enter the same editable state as a double-click
from a programmatic action (place caret + activate the ContentBox editor)? - Can the popup Edit action be fixed to match double-click behavior?
- Can the delete path be hardened against the core crash above?
Current workaround: we hide the popup Edit button for content-edit placeholders
via UI.disableElements([‘annotationContentEditButton’]) and ask users to
double-click to edit. We’d prefer a proper fix.
Please provide a link to a minimal sample where the issue is reproducible:
JavaScript PDF Text Editing Demo | Apryse WebViewer