[#48629] - [AI] [6.2] Only close close-on-message dialogs on Joomla messages
- Pending
- Medium
- Build: 5.4-dev
- # 48629
- Diff
- genr8r:fix/dialog-close-on-foreign-message
User tests: Successful: Unsuccessful:
Pull Request resolves #48626 .
- 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
Dialogs opened with data-close-on-message (Add Module on dashboards, Menus "Add module", Smart Search and Redirect plugin dialogs) closed on any message event posted from the dialog iframe. Browser extensions that inject scripts into iframes (Bitwarden's inline autofill, for example) post their own messages to the parent window, so the dialog closed as soon as it opened.
The handler now ignores messages whose messageType does not start with joomla:. All core close paths go through the modalreturn layouts, which post via modal-content-select with a joomla: message type, so they are unaffected.
Testing Instructions
- Log in to Bitwarden in your browser (inline autofill menu on, the default).
- Go to System Dashboard and click "Add module to the dashboard".
- Select a module type, give it a title, Save & Close.
Without Bitwarden, you can simulate the extension from the browser console. The message has to be posted from inside the dialog's iframe, because the handler only reacts to messages whose source is the iframe window:
- Click "Add module to the dashboard" and wait for the module type list to load in the dialog.
- Open DevTools > Console and switch the context dropdown (top left of the console,
topby default) to the dialog's iframe. - Run:
parent.postMessage({command: 'test'}, '*')Running it with the console context left on top sends the message from the top window, which the handler ignores with or without this PR, so the dialog stays open either way.
Make sure the browser isn't using a cached copy of the old script: tick "Disable cache" in DevTools > Network and hard-reload the dashboard after applying or reverting the PR.
Actual result BEFORE applying this Pull Request
The dialog appears and closes immediately (or when the console command above runs) and the dashboard reloads.
Expected result AFTER applying this Pull Request
The dialog stays open on foreign messages. Saving the module still closes the dialog and reloads the dashboard.
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
🤖 Generated with Claude Code
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | JavaScript Repository NPM Change |
| Title |
|
||||||
| Status | Pending | ⇒ | Closed |
| Closed_Date | 0000-00-00 00:00:00 | ⇒ | 2026-10-17 07:30:51 |
| Closed_By | ⇒ | genr8r | |
| Labels |
Added:
NPM Resource Changed
bug
PR-5.4-dev
|
||
| Status | Closed | ⇒ | New |
| Closed_Date | 2026-10-17 07:30:51 | ⇒ | |
| Closed_By | genr8r | ⇒ |
| Status | New | ⇒ | Pending |
| Title |
|
||||||
| Category | JavaScript Repository NPM Change | ⇒ | Administration Language & Strings JavaScript Repository NPM Change Installation Libraries |
| Labels |
Added:
Language Change
PR-6.2-dev
|
||
| Category | JavaScript Repository NPM Change Administration Language & Strings Installation Libraries | ⇒ | JavaScript NPM Change |
Reopened and retargeted to 6.2-dev, since 5.4 only takes security fixes now. The branch is rebased onto 6.2-dev with the change moved to the new path media_source/system/js/joomla-dialog-autocreate.es6.js. The code change itself is the same.
The bug is still present in current stable releases (Bitwarden logged in, inline autofill on, "Add module to the dashboard"):
| Version | Dialog script | Result |
|---|---|---|
| 6.1.1 stable | stock | dialog closes immediately |
| 6.2.0 stable | stock | dialog closes immediately |
| 6.2.1-dev | this PR | dialog stays open |
The handler is also unchanged on 6.3-dev and 7.0-dev, so this will merge up cleanly.
@exlemor, thanks again for testing at JWC. If you have time to retest against 6.2, the console simulation in the testing instructions works without Bitwarden.
document.querySelector('joomla-dialog iframe').contentWindow.eval("parent.postMessage({command: 'test'}, '*')")
Please do not post such examples even for test 😄
document.querySelector('joomla-dialog iframe').contentWindow.parent.postMessage({command: 'test'}, '*');
Should work perfectly fine.
The dialog appears and closes immediately (or on the console message above) and the dashboard reloads.
This was done because usualy there nothing else to do after module added and saved.
Please tell us your use case, maybe we could extend this part somehow.
Suggested code is a bit conflicting in the logic. I mean for closeOnMessage property.
document.querySelector('joomla-dialog iframe').contentWindow.eval("parent.postMessage({command: 'test'}, '*')")
Please do not post such examples even for test 😄
document.querySelector('joomla-dialog iframe').contentWindow.parent.postMessage({command: 'test'}, '*');
Should work perfectly fine.
The dialog appears and closes immediately (or on the console message above) and the dashboard reloads.
This was done because usualy there nothing else to do after module added and saved.
Please tell us your use case, maybe we could extend this part somehow.
Suggested code is a bit conflicting in the logic. I mean for closeOnMessage property.
I mean how Bitwarden connected to Joomla add module?
It seems totaly unrelated, and looks like bug on their side.
document.querySelector('joomla-dialog iframe').contentWindow.eval("parent.postMessage({command: 'test'}, '*')")
Please do not post such examples even for test 😄
document.querySelector('joomla-dialog iframe').contentWindow.parent.postMessage({command: 'test'}, '*');
Should work perfectly fine.
The dialog appears and closes immediately (or on the console message above) and the dashboard reloads.
This was done because usualy there nothing else to do after module added and saved.
Please tell us your use case, maybe we could extend this part somehow.
Suggested code is a bit conflicting in the logic. I mean for closeOnMessage property.
I mean how Bitwarden connected to Joomla "add module"?
It seems totaly unrelated, and looks like bug on their side.
@Fedik thanks for looking at this.
You're right about eval, I'll remove it from the testing instructions. One catch with the replacement: when the message is posted from the top window, message.source is the top window, not the iframe, so the current handler ignores it and the dialog stays open even without this PR. To reproduce, the message has to come from inside the iframe. Without eval, that means switching the DevTools console context to the dialog's iframe and running parent.postMessage({command: 'test'}, '*'). I'll update the instructions to say that.
To clarify the bug: closing after the module is saved is fine and this PR keeps that. The problem is that the dialog closes before the user can pick a module type:
- Click "Add module to the dashboard". The dialog opens.
- A browser extension running inside the dialog's iframe posts a message to the parent window. Password managers do this to position their autofill menus. Bitwarden is just the one I hit.
- The
closeOnMessagehandler accepts any message from the iframe, so the dialog closes and the dashboard reloads.
Posting to the parent window is normal extension behaviour, so I don't think this is a Bitwarden bug. The handler is broader than it needs to be. Only users with such extensions are affected, but when it happens nothing explains why the dialog vanished, and they can't add a module at all.
On the closeOnMessage logic: every core sender (modal-content-select, used by the modalreturn layouts) sets a joomla: message type, so in practice "close on message" already means "close on a Joomla message". The PR just makes that explicit. If you'd rather match only joomla:content-select and joomla:cancel, I'm happy to tighten it.
Okay, all good then. If PR get tested it is okay have this restriction.
Okay, all good then. If PR get tested it is okay to have this restriction.
Hi @genr8r, during JWC 2026 with you, I was able to test 1 time successfully but then when we re-did it, it didn't work so I can't make it a successful test as you know.