Progress!
The problem is the difference between what the textarea returns as value, and what was the starting value. When using a RTE like TinyMCE or Redactor, there is always some code cleaning going on, enforcing root elements etc. After some serious core-extjs digging, I can reliably reproduce this in both Chrome and Firefox (both latest) in MODX 2.2.11.
I have been testing on three random resources. The problem only occurred on two. The first one had this as content:
<p>[[!Login? &preHooks=`preHook.DiscussLogin` &postHooks=`postHook.DiscussLogin` &loginTpl=`lgnTplMODX`]]</p>
In that case, the dirty checking by the ExtJS core would load the value of the textarea after the RTE was initiated, which suddenly had encoded ampersands, like such:
<p>[[!Login? &preHooks=`preHook.DiscussLogin` &postHooks=`postHook.DiscussLogin` &loginTpl=`lgnTplMODX`]]</p>
In this case, the dirty form check saw two different values, the field was marked dirty, and the navigation confirmation was shown.
The second resource only had this as content:
<p>You will update your profile here.</p>
The RTE did not do anything with this. Content stayed the same, field was not marked dirty, no navigation confirmation as expected.
The third one had me puzzled for a moment, but its content was
and the RTE turned it into
which was different -> marked dirty -> navigation confirmation.
So that's the problem. I'm not sure why this initially seemed to be limited to Firefox (I can reproduce the above consistently across both FF and Chrome, both on Mac) but I'm guessing different resources were used in testing.. different content, as illustrated, will have different results. This may also be why Jason could not reproduce it, as I bet he doesn't use a RTE
I'm now working on a patch that checks for the navigation warning differently, which should be more reliable and not depend on weird side effects of RTEs like this. Spoiler: the same way the Save button is enabled or disabled.