[#48246] - [6.2] Fix consecutive layout shifts caused by replacing administrator success messages
- Pending
- Medium
- Build: 5.4-dev
- # 48246
- Diff
- alwaysalearner1234:fix-issue-48182
User tests: Successful: Unsuccessful:
Pull Request resolves #48182 .
- I read the Generative AI policy and my contribution is either not created with the help of AI or is compatible with the policy and GNU/GPL 2 or later.
Summary of Changes
This PR fixes Issue #48182, which reported consecutive layout shifts occurring when an administrator rapidly replaces notifications of the same type (such as repeatedly toggling/disabling dashboard modules).
Changes made:
- In-place updates for matching alerts: When
Joomla.renderMessages()renders incoming messages withkeepOld: false, it now checks if a<joomla-alert>of the matching type already exists. If it exists, it updates the existing alert's.alert-wrapperin-place and resets theauto-dismisstimeout. This avoids removing and re-inserting elements of the same type, completely eliminating unnecessary consecutive layout shifts. - Preserved animations:
Joomla.removeMessages()remains completely unchanged and usesalert.close(). Any alerts of different un-reused types will still fade out usingalert.close(), preserving intended animation behavior across the CMS.
Testing Instructions
- Open the Joomla Administrator Control Panel (
/administrator). - On the Home Dashboard, disable or unpublish a module (e.g. "Latest Articles"). A success message will appear.
- While the first success message is still visible, disable another module (e.g. "Sample Data").
- Observe the message container behavior.
- Click the "X" button on an alert to test manual dismissal.
Actual result BEFORE applying this Pull Request
- The new success message is inserted below the existing one (causing the page to jump down).
- The old message then finishes fading out and is removed (causing the page to jump back up).
- Single user action causes two consecutive layout shifts.
Expected result AFTER applying this Pull Request
- The existing success message smoothly updates its text in-place.
- No consecutive layout shifts or page jumps occur.
- Manually clicking the "X" dismiss button still smoothly animates the alert out as expected.
Link to documentations
Please select:
-
Documentation link for guide.joomla.org:
-
No documentation changes for guide.joomla.org needed
-
Pull Request link for manual.joomla.org:
-
No documentation changes for manual.joomla.org needed
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | JavaScript Repository NPM Change |
@alwaysalearner1234 Please stick with the pull request template.
You have removed the AI policy confirmation. Please add that back and check the check box to confirm the AI policy.
In addition, please add a Pull Request resolves #48182 . to the top so the issue is correctly referenced. That was also a part of the pull request template which you have removed.
Finally, why do you make a PR for the 5.4-dev branch but use "[6.1]" in the title? If the issue exists also in 5.4., then a PR to the 5.4-dev branch is right, but then the title should start with "[5.4]". But if the issue exists only in 6.x but not in 5.4, then the PR should be made for the 6.1-dev branch. See also here: https://github.com/joomla/joomla-cms#which-branch-should-my-pull-request-target
Please check and fix.
Thanks in advance.
@alwaysalearner1234 Please stick with the pull request template.
You have removed the AI policy confirmation. Please add that back and check the check box to confirm the AI policy.
In addition, please add a Pull Request resolves #48182 . to the top so the issue is correctly referenced. That was also a part of the pull request template which you have removed.
Finally, why do you make a PR for the 5.4-dev branch but use "[6.1]" in the title? If the issue exists also in 5.4., then a PR to the 5.4-dev branch is right, but then the title should start with "[5.4]". But if the issue exists only in 6.x but not in 5.4, then the PR should be made for the 6.1-dev branch. See also here: https://github.com/joomla/joomla-cms#which-branch-should-my-pull-request-target
Please check and fix.
Thanks in advance.
Update: I've just got the information that the issue exists also in 5.4, so the base branch is right for this PR.
| Title |
|
||||||
| Labels |
Added:
NPM Resource Changed
PR-5.4-dev
|
||
Thank you for the review! I have updated the implementation so that Joomla.removeMessages() and alert.close() animations are completely preserved. The fix now updates alerts of the same type in-place in Joomla.renderMessages() to eliminate layout shifts without removing the close animation.
| Title |
|
||||||
I have tested this item 🔴 unsuccessfully on 5e103bf
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48246.
I have tested this item 🔴 unsuccessfully on 5e103bf
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48246.
As you can see in the video the alert message is remove almost immediately without any user interaction
thorium_LgVDZa14iB.mp4
The existing success message smoothly updates its text in-place.
to my eyes i dont see any smooth update - I just assumed that there had been no change at all
Personally I would fade out the existing message and then load the new message in its place.
Before this PR the message would fade out and the next message would be displayed while it was being faded - hence the layout shift
Instead what should happen is the message should fade out and then the next message should be displayed
@brianteeman The reason it looked like nothing changed is that both module unpublish actions produce the exact same message string ("Module successfully unpublished"). Because the alert box remained completely static with zero layout movement, the instantaneous text swap was imperceptible.
If we completely fade out and remove the alert before inserting the new one, the container height collapses to 0px and expands again, causing the same layout shifts.
To solve this, I've added a subtle 250ms opacity refresh animation to the message content on in-place updates (commit 3bb29c1). This gives immediate visual feedback that the action succeeded and the notification refreshed, while keeping the container dimensions completely stable without any layout shifts or jumps.
The reason it looked like nothing changed is that both module unpublish actions produce the exact same message string ("Module successfully unpublished"). Because the alert box remained completely static with zero layout movement, the instantaneous text swap was imperceptible.
If we completely fade out and remove the alert before inserting the new one, the container height collapses to 0px and expands again, causing the same layout shifts.
To solve this, I've added a subtle 250ms opacity refresh animation to the message content on in-place updates (commit 3bb29c1). This gives immediate visual feedback that the action succeeded and the notification refreshed, while keeping the container dimensions completely stable without any layout shifts or jumps.
I have tested this item ✅ successfully on 31d6c07
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48246.
I have tested this item ✅ successfully on 31d6c07
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/48246.
| Category | JavaScript Repository NPM Change | ⇒ | Administration com_templates JavaScript Repository NPM Change |
| Category | JavaScript Repository NPM Change Administration com_templates | ⇒ | JavaScript Repository NPM Change |
I don't see where this is better then before
Bildschirmaufnahme_20260816_105949.webm
I don't see where this is better then before.
Bildschirmaufnahme_20260816_105949.webm
And it removes an unrelated notification (not sure if this is also done before)
I don't see where this is better then before.
Bildschirmaufnahme_20260816_105949.webm
And it removes an unrelated notification (not sure if this is also done before)
@HLeithner strange - maybe its browser dependent?
thorium_36UBorS96a.mp4
And it removes an unrelated notification (not sure if this is also done before)
yes the statistics message is removed before - no change here
@HLeithner strange - maybe its browser dependent?
@brianteeman same effect on vivaldi and firefox, I installed the prebuilt package so should be the right version...
@brianteeman can you create a video how it should look like please?
ah missed it or I think I watched the wrong video and thought it's yours... anyway, main question is this better? removing a message and showing the same message again without the user noticing it? I think we had a discussion some years ago. where we said it's better to have the jump then a "silent" message.
I'm still not convinced that this is better then the shift. Also that unrelated messages are closed (I know it's unrelated but comes up now (again?)) should be adressed.
I have no opinion on if it's better or not. From an a11y perspective it's possibly better to not have a layout shift but I leave that to the a11y review
| Labels |
Added:
bug
|
||
| Category | JavaScript Repository NPM Change | ⇒ | Repository Administration com_admin SQL |
| Title |
|
||||||
| Category | Repository Administration com_admin SQL | ⇒ | JavaScript NPM Change |
| Labels |
Added:
PR-6.2-dev
Removed: PR-5.4-dev |
||
As 5.4 has reached end of bugfix support and is now in security only support mode, I've allowed myself to rebase this PR here to 6.2-dev, where bug fixes should be made now. There was a conflict caused by the media_source folder having been moved in the 6.2-dev branch, which I have resolved, but besides that the rebase was clean, so the previous human test is still valid.
As 5.4 has reached end of bugfix support and is now in security only support mode, I've allowed myself to rebase this PR here to 6.2-dev, where bug fixes should be made now. There was a conflict caused by the media_source folder having been moved in the 6.2-dev branch, which I have resolved, but besides that the rebase was clean, so the previous human test is still valid.
P.S.: I've also allowed myself to fix CS issues reported by the JS linter because that is a newer version in 6.2-dev which is detecting more issues than it does in 5.4-dev.
That's not the correct solution, you remove the animation with the pr I think what's not intended