Surface Drupal messages as small top-right toasts, auto-dismissed

Two problems: (1) the node form's modal AJAX submit handler (figli_compta_ledger_node_form_ajax_submit) closed the dialog on success without ever surfacing whatever messenger() had queued during save() -- e.g. NodeForm's own "Ligne comptable X has been updated." Since the /lignes table only ever refreshes via AJAX afterwards, never a full page load, that message was silently lost instead of just delayed. Now forwarded via MessageCommand before closing the modal. (2) Gin's default message styling is a full-size flash banner meant for a single admin form, in-flow (pushing the page down) and far too large for frequent background feedback on this dashboard. admin-chrome.css repositions [data-drupal-messages] / [data-drupal-messages-fallback] to fixed top-right (out of document flow, so nothing shifts) and shrinks text/padding/dismiss-button size drastically while keeping them legible. admin-chrome.js auto-dismisses non-error messages after 2s via a MutationObserver (Drupal.Message.add() just appends a DOM node, it never re-fires attachBehaviors(), so behaviors/once() would miss anything added after the initial page load); error messages are left alone, requiring the existing manual click on Gin's own dismiss button. Both attached globally via the existing admin_chrome library (already loaded on every page for the phantom-top-bar fix), consistent with that precedent. Verified: a real full-form save on a clean node returns exactly {message (status, "has been updated"), closeDialog} in that order: a répartition-inconsistent node still correctly blocks the full form (unaffected, skip_validation is never used here); a synthetic status/warning/error trio confirms fixed positioning, no layout shift, ~40% smaller text, and status/warning auto-hiding while error persists until manually dismissed.
2026-09-04 22:17:52 +02:00
parent 3ec894c167
commit 2947a542da
4 changed files with 148 additions and 0 deletions
@@ -0,0 +1,64 @@
+/**
+ * @file
+ * Non-error Drupal status messages (status/warning) auto-dismiss after a
+ * couple seconds; error messages always require an explicit click on
+ * Gin's own dismiss button (.js-message-button-hide) -- something that
+ * needs attention shouldn't vanish on its own.
+ *
+ * Drupal.Message.add() (used both for messages already in the initial
+ * page render and for MessageCommand-driven AJAX messages) just appends a
+ * DOM node directly -- it never re-fires Drupal.attachBehaviors(), so a
+ * behaviors/once()-based approach would miss anything added after the
+ * initial page load. A MutationObserver sees every insertion path.
+ */
+(function (Drupal) {
+  'use strict';
+
+  var AUTO_DISMISS_MS = 2000;
+
+  function dismiss(el) {
+    var btn = el.querySelector('.js-message-button-hide');
+    if (btn) {
+      btn.click();
+    } else {
+      el.style.opacity = 0;
+      el.classList.add('visually-hidden');
+    }
+  }
+
+  function handleMessage(el) {
+    if (el.dataset.figliAutoDismissSeen) return;
+    el.dataset.figliAutoDismissSeen = '1';
+    if (el.classList.contains('messages--error')) return;
+    setTimeout(function () {
+      dismiss(el);
+    }, AUTO_DISMISS_MS);
+  }
+
+  function scan(root) {
+    root.querySelectorAll('.messages-list__item').forEach(handleMessage);
+  }
+
+  function init() {
+    scan(document);
+    new MutationObserver(function (mutations) {
+      mutations.forEach(function (mutation) {
+        mutation.addedNodes.forEach(function (node) {
+          if (node.nodeType !== 1) return;
+          if (node.classList && node.classList.contains('messages-list__item')) {
+            handleMessage(node);
+          }
+          if (node.querySelectorAll) {
+            scan(node);
+          }
+        });
+      });
+    }).observe(document.body, { childList: true, subtree: true });
+  }
+
+  if (document.readyState === 'loading') {
+    document.addEventListener('DOMContentLoaded', init);
+  } else {
+    init();
+  }
+})(Drupal);