Edit form: Clone .gin-sticky, keep event-bindings

Created on 25 June 2021, almost 3 years ago
Updated 6 February 2023, over 1 year ago

Problem/Motivation

Since version alpha34, Gin provides a JS-routine that moves ("clones") the initially hidden .gin-sticky-container (containing usually action-buttons for the edit-form) from the bottom of the page to the upper .region-sticky__items__inner. This takes place in the file js/gin_editform.js.

The cloning of this node is done via vanilla JS method Node.cloneNode. However, this method does not duplicate any events bound on the action buttons within that container. Therefore, custom event listeners being attached by other modules (such as previewer β†’ ) will stop functioning.

Steps to reproduce

- Install previewer module β†’ .
- Activate any other admin-theme (e.g. Claro), open any edit form and hit "Preview" button: An AJAX-method is executed and an off-canvas element is loaded.
- Activate Gin admin theme, open any edit form and hit "Preview" button: The AJAX-method is not present any more on that button and the page will simply reload.

Proposed resolution

As a matter of fact, jQuery (which is in scope of gin_editform.js) does provide a clone-method that keeps any event-bindings and was confirmed to work with the mentioned preview-module:

...
l9: const sticky = $('.gin-sticky').clone(true, true);
...
l13: sticky.appendTo($(newParent));
...

One could therefore propose two solutions:
- a) Clone the node via jQuery.clone() and attach it via jQuery.appendTo(). This depends on the maintainers opinion on whether to continue supporting jQuery over plain vanilla JS in future times.

- b) Find a vanilla-JS based solution to clone nodes by keeping their event-bindings. According to stackoverflow, there seems to be no out-of-the-box solution for that, besides more or less re-building jQuery.clone() (?!).

User interface changes

None

API changes

None

Data model changes

None

πŸ› Bug report
Status

Fixed

Version

3.0

Component

User interface

Created by

πŸ‡©πŸ‡ͺGermany FlxAlbroscheit

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

Comments & Activities

Not all content is available!

It's likely this issue predates Contrib.social: some issue and comment data are missing.

  • πŸ‡©πŸ‡ͺGermany berliner

    Having implemented my own version of previewer, not aware that the module existed, I have just run into this now when switching the backend theme from Claro to Gin for one of my projects. While trying to see what breaks the ajax on the preview button, I have also installed the previewer module and tested with every single release of Gin since alpha33, which is the last version where both the previewer module and my custom implementation worked.

    So this issue does not seem to have been solved actually. Using the current rc1, I can confirm that code attaching an ajax event to the node edit preview button (using #ajax

    I'll try to debug this further to find the issue.

  • πŸ‡©πŸ‡ͺGermany berliner

    Wasted time :( So it seems to be an issue with Chromium based browsers, which apparently don't like it if the id of input changes that had previously been bound by the Drupal.Ajax logic. I have reached my horizon here, and given that it is limited to chromium and browser based on that, I'll be going to ignore this issue for now.

Production build 0.69.0 2024