Attach (recommended) or Link to PDF file
https://github.com/mozilla/pdf.js/blob/master/test/pdfs/annotation-text-widget.pdf (from the PDF.js test corpus; any AcroForm with text fields shows it)
Web browser and its version
Chromium 153 (headless Playwright build and desktop)
Operating system and its version
macOS 26.5
PDF.js version
6.5.76 (https://mozilla.github.io/pdf.js/web/viewer.html), also 6.4.299 (pdfjs-dist viewer components)
Is the bug present in the latest PDF.js version?
Yes
Is a browser extension
No
Steps to reproduce the problem
- Open the form in the viewer.
- Click once on an empty area of the page (no text, no field), e.g. the margin.
- Click once into a text field.
What is the expected behavior?
The field gets the focus with the first click, like it does when nothing was clicked before.
What went wrong?
The first click on the field does nothing, only a second click focuses it. document.activeElement after step 3 is the text layer div, document.elementFromPoint() at the centre of the field returns the text layer's .endOfContent.
Cause: the click in step 2 leaves a collapsed selection (a caret) that intersects the text layer. mousedown on the text layer adds the class selecting (web/pdf_viewer.mjs, TextLayerBuilder#bindMouse), and the selectionchange handler keeps it as long as a range intersects the layer (isFirefoxOrModernChromium branch in the same file), which is the case for the collapsed selection. With selecting, .endOfContent is expanded over the whole page and sits above the annotation layer, so the next click lands on it instead of on the field. Only that click changes the selection, which removes selecting; the second click then reaches the field.
Reproduced the same way in a pdfjs-dist 6.4.299 embedding and in the reference viewer (6.5.76). A collapsed selection should probably not count as "selecting" (e.g. range.collapsed check in the selectionchange handler), or mouseup without a selection should remove the class.
Attach (recommended) or Link to PDF file
https://github.com/mozilla/pdf.js/blob/master/test/pdfs/annotation-text-widget.pdf (from the PDF.js test corpus; any AcroForm with text fields shows it)
Web browser and its version
Chromium 153 (headless Playwright build and desktop)
Operating system and its version
macOS 26.5
PDF.js version
6.5.76 (https://mozilla.github.io/pdf.js/web/viewer.html), also 6.4.299 (
pdfjs-distviewer components)Is the bug present in the latest PDF.js version?
Yes
Is a browser extension
No
Steps to reproduce the problem
What is the expected behavior?
The field gets the focus with the first click, like it does when nothing was clicked before.
What went wrong?
The first click on the field does nothing, only a second click focuses it.
document.activeElementafter step 3 is the text layerdiv,document.elementFromPoint()at the centre of the field returns the text layer's.endOfContent.Cause: the click in step 2 leaves a collapsed selection (a caret) that intersects the text layer.
mousedownon the text layer adds the classselecting(web/pdf_viewer.mjs,TextLayerBuilder#bindMouse), and theselectionchangehandler keeps it as long as a range intersects the layer (isFirefoxOrModernChromiumbranch in the same file), which is the case for the collapsed selection. Withselecting,.endOfContentis expanded over the whole page and sits above the annotation layer, so the next click lands on it instead of on the field. Only that click changes the selection, which removesselecting; the second click then reaches the field.Reproduced the same way in a
pdfjs-dist6.4.299 embedding and in the reference viewer (6.5.76). A collapsed selection should probably not count as "selecting" (e.g.range.collapsedcheck in theselectionchangehandler), ormouseupwithout a selection should remove the class.