When performing a drag and drop operation the target window, record, and field would activate and run appropriate triggers.
Why This Is Important
Today, when you drag and drop contents onto a field, the field does not activate and does not run any triggers. This can cause unexpected results if not designed for when using triggers for validation, data cleansing, running scripts, etc...
There are some work arounds as pointed out by jbrown in this article. However, it seems like it is a natural expectation that if you're dropping contents into a field, the net result is the field becomes active and associated triggers would run.
This design limitation originally surfaced in FileMaker Pro 10, in 2009 when script triggers were first introduced. Recently, in 2018, confirmed that the "drop" behavior intentionally bypasses the field and talks directly to the database engine, whereby circumventing script triggers.
Perhaps since it's gone this long without much attention is why it has stayed the same with no plans to change it, but I don't believe it's the right/expected behavior when it requires workaround to guard against and limits what is possible.
Cloudbase Software, Inc.