Hand tool prevents custom JavaScript validation

Attach (recommended) or Link to PDF file here: pdf_form_js_validation_problem.pdf

Configuration:

• Web browser and its version: doesn’t matter
• Operating system and its version: doesn’t matter
• PDF.js version: current source code on GitHub; 2.13
• Is a browser extension: no

Steps to reproduce the problem:

1. Navigate to https://mozilla.github.io/pdf.js/web/viewer.html
2. Activate the hand tool
3. open the attached PDF file
4. enter letters into the input field
5. click somewhere outside the input field to trigger validation --> there’s no validation. Plus, the input is lost, but it re-appears after entering the input field again.
6. However, leaving the field using the TAB key does trigger validation

What is the expected behavior? (add screenshot)

What went wrong? (add screenshot)

There’s a conflict between these lines: https://github.com/mozilla/pdf.js/blob/20d60d92ba3c701d79a62db2b8ff7899e752925e/web/grab_to_pan.js#L58 https://github.com/mozilla/pdf.js/blob/20d60d92ba3c701d79a62db2b8ff7899e752925e/web/grab_to_pan.js#L71

and this line: https://github.com/mozilla/pdf.js/blob/869b396011b03d00325f2a5d5c01e58841efc312/web/pdf_scripting_manager.js#L157

After removing the last parameter from the grab_to_pan file (i.e. making it this.element.removeEventListener("mousedown", this._onMouseDown)), everything works as expected. Alternatively, I assume you could also add a , true to the pdf_scripting_manager line (but I didn’t test it yet).

However, I don’t know if there are side effects. Digging into the history of the grab-to-pan class reveals the additional parameter was there from day 1 of the external project written by @Rob--W (https://github.com/Rob--W/grab-to-pan.js), so I suspect it’s not really necessary.

Link to a viewer (if hosted on a site other than mozilla.github.io/pdf.js or as Firefox/Chrome extension):

[Snuffleupagus]

BTW, I suggest binding the event to the PDF viewer instead of binding it to the document:

Please note that that’s first of all unrelated to this issue, and secondly would actually change behavior (since it’d miss clicks outside of the viewer DOM element), and finally we try to avoid unnecessary DOM-lookups sprinkled throughout the viewer code (i.e. why getViewerConfiguration exists).

---

Given that this issue only happens when GrabToPan is used, a fix in that code specifically feels like the correct approach here!

[Rob--W]

GrabToPan registers a mousedown listener with capture=true to ensure that the element can be grabbed. When grabbing starts, it calls event.preventDefault() to prevent the browser from activating the default behavior for a mouse press on the element (e.g. text selection), and event.stopPropagation() is called to prevent other listeners in the web page from interfering with the panning process (source). Not doing either of these actions can break the panning functionality. The implementation currently makes an exception for input elements and links: when the user presses the pointer in one of these elements, the panning functionality does not activate.

pdf_scripting_manager.js uses the mousedown event to keep track of the mouse state (details below). Because of that, it would make most sense to register the listener with capture=true, even without GrabToPan. I’ll submit a PR for that.

An alternative is to remove the event.stopPropagation() call, but that may introduce regressions. Besides, it’s inconsistent to call preventDefault() without stopPropagation().

The scripting implementation relies on the mousedown/mouseup events to detect whether the mouse was down, and when that was the case, simulate a Keystroke scripting event that runs the validation

• isDown updated by mousedown/mouseup in web/pdf_scripting_manager.js#L146-L157.
• isDown used during blur event at src/display/annotation_layer.js#L1031.
• Keystroke runs validation at src/scripting_api/event.js#L137-L140