Contrib.social

"Experimental" autosave on form change is enabled, but doesn't work.

Open on Drupal.org →
Created on 18 October 2024, 6 months ago

Problem/Motivation

The autosave functionality on form change is not working as expected when the "Run only on form change" setting is enabled. I understand that this feature is currently "experimental" in the current version. This setting is highly requested by Drupal authors I work with as the timing mechanism is good but doesn't capture changes sometimes unless the timer is short.

Note: The provided patch may address specific use cases for my needs only, but I am hopeful that this could initiate a broader discussion towards making the feature more functional for all entities configured for autosave.

Steps to reproduce

  1. Go to the autosave form settings and enable "Run only on form change."
  2. Open a form that supports autosave.
  3. Make changes to the form and observe the behavior.
  4. Note that the form is not autosaved after changes.

Proposed resolution

  • Update the JavaScript logic to correctly track changes in the form.
  • Introduce a debounce mechanism to prevent frequent autosave triggers when minor changes occur.
  • Ensure that CKEditor instances are properly initialized and monitored for changes to trigger autosave.
  • Modify existing functions to correctly identify form changes and trigger autosave accordingly.

Again, the above may target my specific cases. For instance, the patch includes factoring in nested/collapsed paragraphs and some JS included here specifically is to reinitialize the Autosave to work for nested CKEditors.

Part of the patch is merely migrating some functions to a higher level to make it easier to reference elsewhere in the file.

Remaining tasks

  • Test the updated JavaScript functionality on different types of forms, including those with CKEditor fields and paragraph components.
  • Verify that autosave is triggered only when form data changes, and no autosave is triggered when no changes are made.
  • - Confirm that the debounce mechanism works effectively to prevent frequent triggers.

User interface changes

No visible UI changes are expected. However, users should notice a difference in the autosave behavior, where autosaves now occur only when changes are detected.

API changes

No API changes are expected.

Data model changes

No data model changes are expected.

If there happens to be another thread I've missed that targets this specific issue, please tag it here as I couldn't find a thread that relates.

🐛 Bug report
Status

Active

Version

1.6

Component

Code

Created by

🇺🇸United States jv24

Live updates comments and jobs are added and updated live.
Sign in to follow issues

Comments & Activities

  • Issue created by @jv24
  • Comment 6 months ago →
    🇺🇸United States jv24
  • Status changed to Needs review about 1 month ago
  • Comment about 1 month ago →
    🇺🇸United States jonraedeke

    This patch is working really well. Thank you for doing this work, it's a major improvement. Previously, CKEditor5 was not triggering a change when "Run only on form change" was enabled.

    One minor suggestion is to change the label for this option to "Run on form change" since it no longer uses "The interval to use for triggering autosave in milliseconds." setting when enabled.

  • Comment 3 days ago →
    🇩🇪Germany Fabianx

    I reworked the approach in the following way:

    - The autosaveFormMonitor was unreliable, so I switched strategy to check for changes before submitting the form
    - I also re-added a debounce delay (inspired by the patch here), so that a save with skip_checks = TRUE is scheduled when changes are detected
    - As there was always two save, I chose to ignore changes to autosave_last_autosave_form form key

    Therefore:

    We check for changes e.g. every 500 ms [interval check], but only submit the form if there are changes.

    If debounceDelay is set then this save is debounced for 5 seconds. So as long as the user is typing, we don't autosave!

    - TODO: Right now the debounceDelay is hard-coded to 5 seconds

    Grok explanation:

    Replaced the unreliable autosaveFormMonitor behavior with a robust hasFormChanges function for detecting form changes.

    The new method compares current form values (formValues) against stored latestFormValues, excluding fields like autosave_form_last_autosave_timestamp via excludeFields, ensuring accurate detection of meaningful changes without relying on event-based monitoring.

    This is implemented in triggerAjaxSubmitWithoutProgressIndication, where beforeSubmit uses hasFormChanges to decide if a save is needed, respecting onlyOnFormChange.

    As an optional enhancement, I added debounceDelay (default: 5000ms) and debounceTimer to Drupal.autosaveForm. When set, it schedules saves after a delay only if no further changes occur, triggered with skip_checks = true. The form submit handler clears both interval and debounce timers to prevent conflicts. These changes remove Drupal.behaviors.autosaveFormMonitor, improve reliability, and support configurable debouncing via drupalSettings.autosaveForm.

    Patch is attached, but still need to update the IS.

  • Comment 3 days ago →
    🇩🇪Germany Fabianx
contrib.social Blog FAQ Discussions
Production build 0.71.5 2024