The video and sample file are helpful. I read your post this morning, and it took a while before I really could reproduce and then understand the point that you raise in your post.
The methodology of how one first attempts to commit the record seems to factor into the success/failure of the subsequent revert step.
If I take your sample file, and I go to the layout that "works", and I add another simple button that just commits the record, I can elicit a different result as follows:
1) in the web browser, get to the "works" layout with the new added "commit" button
2) click into a field to get into editing mode
3) clear either or both fields
4) use the new commit button that we added to the layout to attempt to save changes
5) see validation message
6) dismiss validation message
7) click the "revert" button
8) see the validation message again (i.e. just as in the fail case that you demonstrated in the video)
If I follow the above steps with the slight change of using the toolbar "Submit" button instead of the layout commit button (just like in your video) it works as expected.
One other note:
In the failure case that I describe above, clicking the 'revert' button a second time functions properly, i.e. click it, see the validation message which shouldn't happen, click it again, and the revert happens as it should.
As for workarounds:
I'll attach a modified version of your demo file where I've added a sort of proof-of-concept for something which I think has potential as a workaround for this bug. The actual concept is easy -- the harder part would be to get it to match the look and feel of your IWP layout. This could be done in at least a couple of ways -- I'm not sure I'm even settled on what would be best, but, for now, just to run this by you I'm attaching the concept.
Thanks for the reply and the clever work-around; that's a pretty cool trick! I hadn't noticed the different behavior depending on the method of committing the record.
Unfortunately, I don't know how I could incorporate that work-around into the solution I'm working on because I use a different layout to edit records, so clicking a "Cancel" button needs to perform a script to return the user to the previous layout.
Another aspect of this bug I'd like to point out...
If toolbars are hidden and disabled and field validation is triggered, the record MUST be commited. The only way to get the validation message to go away is to modify field contents to satisfy it's validation settings, then even if the user clicks a button to revert the record, it will be commited.
The only work-around I've found for this is to close the browser window and wait for your session to time-out, or have your session closed from FileMaker Server admin panel. If the user logs in again before their session times out, they will be taken back to the open record they were previously editing.
FYI: the sample file by steve works by using a web viewer to inject html into the page when rendered in IWP. It took me a bit to find the web-viewer: it's very small and the background is white. To find it, I deleted all other elements on the layout, then clicked Edit > Selected All, it should be the only element selected now.
I can see how needing to perform a layout change after the revert adds an extra level of trickiness to the problem. I can't think of anything for that off the top of my head, but if I do, I will post again.
I just found a similar issue regarding deleting portal records...
If you delete a portal row from IWP, the only way to revert the delete is via the Cancel button on the toolbar, a button on the layout will always commit the record, therefore delete the portal row.