Add unsaved changes warning to message and diary forms

[phanq003]

Description

Addresses #4898, addresses data loss from accidental navigation aspect of #7044

Users writing diary entries or messages can accidentally navigate away from the page and lose their work. This adds the built-in browser warning (using the beforeunload event) when a user tries to leave a page with edits in progress.

The JavaScript should be able to be used on other forms across the site by adding the data-unsaved-changes-warning attribute to relevant form elements.

Reference: developer.chrome.com/docs/web-platform/page-lifecycle-api#the_beforeunload_event

How has this been tested?

Manually verified that warning appears when trying to navigate away from page with content in diary entry and messages creation, and editing for the former.

Four test cases were added to a new test file for unsaved changes:

• Warn before leaving unsaved diary entry form
• Does not warn when publishing diary entry
• Warns before leaving unsaved message form
• Message form does not warn before any changes are made

[phanq003]

With tests, originally tried to test the beforeunload popup directly using dismiss_confirm, but according to https://makandracards.com/makandra/622849-allow-testing-beforeunload-confirmation-dialogs-modern ChromeDriver 127+ automatically closes the dialogs. This is causing Capybara::ModalNotFound: Unable to find modal dialog.

Attempted to work around this adapting the solution from the mentioned reference, but then would get Selenium::WebDriver::Error::SessionNotCreatedError: session not created: Chrome instance exited.

As a workaround I've used a DOM attribute to keep track of when the listener is attached to be able to test that its there.

[gravitystorm]

I'd like to see a clear discussion about alternative approaches. I'm concerned that this is a lot of hard-to-test code and hard to maintain code.

• Does rails (or hotwire, stimulus etc) offer anything similar?
• Is there a ruby gem or standard javascript library that offers anything similar?
• If this is available in other text editors (e.g. Trix) or similar situations (e.g. iD) can we re-use code from there?
• Is there something

It might be that what is presented here is the best approach, but I would like to see it reasoned out.

---

Also, I'd like to see some reasoning as to which forms should get this warning, and which ones should not. That helps decide whether this PR covers enough of them, or if we can make it enabled by default (since someone adding a new form on the website might not be aware this exists).

[phanq003]

I'd like to see a clear discussion about alternative approaches. I'm concerned that this is a lot of hard-to-test code and hard to maintain code.

* Does rails (or hotwire, stimulus etc) offer anything similar?

* Is there a ruby gem or standard javascript library that offers anything similar?

* If this is available in other text editors (e.g. Trix) or similar situations (e.g. iD) can we re-use code from there?

* Is there something

It might be that what is presented here is the best approach, but I would like to see it reasoned out.

Also, I'd like to see some reasoning as to which forms should get this warning, and which ones should not. That helps decide whether this PR covers enough of them, or if we can make it enabled by default (since someone adding a new form on the website might not be aware this exists).

I haven't had time to research alternative libraries or existing implementations for this, so I can't really say whether there's a library in Rails/hotwire available.

My thinking behind this was that because the underlying logic (beforeunload and event.preventDefault()) is the browser-supported way for implementing warnings like this. At least from a user perspective I've seen similar popups on other websites so it would align with expected browser behaviour.

For the scope of forms, I would think it would mainly be attached to forms where users are creating or editing content over multiple fields, where navigating away would mean meaningful loss of work (e.g. diary entries, profile edits). This would then exclude more temporary forms like searches or login flows. If this was enabled by default, it could be a bit annoying to users when navigating away from the latter, and they'll could end up desensitised to it, which would probably reduce its effectiveness. Of course then there's still the problem of developers being aware it exists though.