Can't revert record when user drag and drops a file from outside FileMaker into a container field (5 Comments)

Issue report by CS8

Product

FileMaker Pro

Version

13

Operating system version

OS X 10.9 and Windows 7

Description of the issue

It's impossible to script a revert record / request in a OnObjectModify script trigger associated to a container field, in case a user drag and drops a file from either Finder or Windows explorer into a FileMaker container field.
FileMaker performs an auto-commit of the record even if auto-commit is disabled under layout options.
This behaviour does not occur if drag and drop is performed from another container field or if the destination field is entered prior to dropping the file.

This can lead to major security issues and database inconsistencies as there is no way to revert the record if a user modifies it by dropping a file into a container field.

Steps to reproduce the problem

1. Create a FileMaker database with one table and two container fields;
2. Create a layout and place both container fields;
3. Define a script trigger "OnObjectModify" on one of the two fields. The attached script should contain a "revert record / request" script step;
4. Create a new, empty record and save it by clicking in an empty area of the screen;
5. Drag and drop a file from any location on the computer to the container field with the active script trigger;
6. Notice that FileMaker fails to revert the record and saves it instead.

Expected result

FileMaker should honour revert record / request whenever a record is changed, whether from an external drag and drop or other user interaction.

Actual result

FileMaker does not revert the record and performs an auto commit making it impossible to script business validation logic that reverts the record prior to the drag and drop action.

Exact text of any error message(s) that appear

None

Workaround

1. If the user clicks into the container field so that focus is on the field itself prior to dropping the file, revert record works as expected.

2. Apply strict field level validation to the container field. In this case the record is not changed if validation fails (even though the validation message does not show).
However, there is currently no way of knowing if the drag and drop originated from outside FileMaker Pro, therefore if one is to allow drag and drop from within FileMaker but disallow it from the outside, they cannot use this workaround.