The constrained movement mode has degraded (1/2)
Operating system version
Description of the issue
In v11 it was fairly easy to move an element strictly horizontally or strictly vertically: you simply hold the Shift key and move it. I actually haven't realized why it felt to simple until today when I did an explicit test. As it turned out, if you inadvertently start moving in a different direction (e.g. you wanted to move the field horizontally, but started the first movement along the vertical axis), you can easily fix this by simply moving the field where you wanted it to be and FileMaker would've switch the constrained axis itself.
In v12 if you started dragging in a different direction, you cannot fix it during dragging. Once the direction is set, it stays. You have to leave the field where you've dragged it (i.e. in a wrong place), undo the movement, and start over. (And undos are also a pain; if you work over WAN, they're very slow. I'll post it as a separate issue.)
And since the mouse in v12 is very sensitive, it makes it much more difficult to drag in the right direction from the first time. I myself almost stopped Shift-dragging; I position by numbers, align to objects, or nudge with keyboard arrows.
Also, there's yet another problem with Shift-dragging; I'll post it separately.
Steps to reproduce the problem
In Layout mode select an object, start moving it vertically or horizontally and hold the Shift key to constrain the movement. Assume you've managed to move it along the vertical axis; now try to move the object to the left or right of its original position because you actually wanted FileMaker to constrain the movement to the horizontal axis.
FileMaker understands your intentions and starts moving the element along the other axis.
Nothing happens; once you started Shift-dragging an object along one axis, you cannot easily switch to another.
Exact text of any error message(s) that appear
Do not use Shift-dragging and move objects by other means. This is theoretically possible, but much less convenient.
Besides, the portals and tabs only "own" an object it it has been explicitly dragged into them and ignore objects that got inside a portal because they were aligned with another object, positioned by numbers, or moved by arrow keys. This leaves no alternative to dragging and since Shift-dragging has become nearly useless, one has to either be extra careful when dragging objects into portals, especially if they have the same height or width as the portal row, or temporarily shrink the object, drag it into the portal to get it "owned", and then move it with arrow keys into the desired position and enlarge it back to the desired size. This is not a joke, I had to actually use it several times in production.