[#46488] - [5.4] Fix: Showon fails open when source field does not exist (hidden by default instead)
- Pending
- Medium
- Build: 5.4-dev
- # 46488
- Diff
- coolcat-creations:fixshowonbehaviour
User tests: Successful: Unsuccessful:
This pull request fixes an issue in Joomla’s showon implementation where dependent fields are always shown, even when the referenced source field does not exist in the DOM.
This “fail-open” behaviour can lead to incorrect form states, invalid UI logic, and unintended visibility of fields.
Problem
Currently, if a field contains something like:
showon="nonexistent_field:1"
and nonexistent_field is not present in the form:
- Joomla does not register any origin fields,
- no event listeners are attached,
- and the dependent field is shown by default.
This is counter-intuitive and causes issues especially in:
- Custom Fields, when a controlling field is deleted or renamed
- Complex XML forms, especially in components or modules using conditional configurations
- Subforms, where dynamic names change and conditions may temporarily point to a non-existing field
This behaviour is likely an oversight rather than an intentional feature.
Expected Behaviour
If the source field defined in showon does not exist, then the condition cannot be fulfilled, therefore the dependent field should be hidden by default.
Solution
This PR adds a simple and safe check in Showon (build/media_source/system/js/showon.es6.js):
After collecting all origin fields for a given showon condition:
if origin.length === 0,
→ the dependent field is immediately hidden,
→ and the joomla:showon-hide event is fired.
This changes the behaviour to Fail closed instead of fail open
(a missing condition hides a field rather than incorrectly showing it)
The fix does not modify the data structure, PHP FormHelper logic, or any API and is fully backward compatible unless someone relied on the previous incorrect behaviour (unlikely).
How to Test
Please test both Custom Fields and standard XML JForm definitions.
1. Test Using Custom Fields
A) Prepare the fields
Go to:
Content → Fields
Create a field:
Field A:
Type: List
Name: controller
Options
List values | Text* | Value |
___________ | Yes _ | 1 |
___________ | No _ | 0 |
Create another field:
Field B:
Type: Text
Name: dependent
Showon: controller:1
B) Test the normal behaviour
Edit an article.
Set “Controller” to "Yes" → Field B should appear.
Set “Controller” to "No" → Field B should hide.
C) Test the missing-source behaviour
Unpublish or Delete Field A (the controller field)
Open the article again.
Expected result after applying the PR:
“Dependent” field is hidden by default
No JS errors occur
Switching values of other fields does not accidentally reveal it
Current behaviour (before PR):
Field B is incorrectly visible.
2. Test Using XML Form Definitions
A) Create a simple XML form (administrator or component)
Example snippet: <field name="dependent" type="text" label="Dependent Field" showon="nonexistent:1" />
B) Load the form in the backend (module, component, plugin etc.)
Expected result after PR:
The “dependent” field is hidden because the source field does not exist.
Current behaviour:
The field is incorrectly shown.
- Test With Multiple Conditions
showon="controller:1[AND]nonexistent:2"
Expected after PR:
Even if controller exists, the missing nonexistent should invalidate the entire condition, hiding the field.
Backward Compatibility
This change should not break valid configurations.
The only difference occurs when showon references a field that:
does not exist,
was renamed,
was deleted,
or is dynamically removed in subforms.
In these cases the new behaviour is more correct and prevents accidental visibility.
This PR makes the showon behaviour more predictable, safer, and consistent by hiding dependent fields when the source field is missing — a long-standing edge case that often leads to incorrect UI states.
| Status | New | ⇒ | Pending |
joomla-cms-bot
- | Category | ⇒ | JavaScript Repository NPM Change |
Yes, when the second condition is not applicable, the field is hidden. ( I described it in the test instructions)
HLeithner
- | Title |
|
||||||
1. Test Using Custom Fields
...
Options: Yes=1, No=0
=> The option description can be improved.
Add two lines in "List Values" like blow
List values | Text* | Value |
___________ | Yes _ | 1 |
___________ | No _ | 0 |
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46488.
@ThomasFinnern changed, thank you - did you test it?
I tried to get there but failed due to lack of my test knowledge.
I exchanged the file in build/... and used npm ci. but the result in fileds was the same.
So i will try again
Anyhow some test cases which you may use in an *.xml file using "controller2"
<field name="controller2" type="radio" label="controller2" default="1" ><option value="0">JNO</option><option value="1">JYES</option></field>
<field name="dependent01" type="text" label="Dependent Field 01" default="!!! Should be shown always !!!" />
<field name="dependent02" type="text" label="Dependent Field 02" default="!!! Should be shown !!!" showon="controller2:1" />
<field name="dependent03" type="text" label="Dependent Field 03" default="!!! Should not be shown !!!" showon="nonexistent:1" />
<field name="dependent04" type="text" label="Dependent Field 04" default="!!! Should not be shown !!!" showon="controller2:1[AND]nonexistent:2" />
<field name="dependent05" type="text" label="Dependent Field 05" default="!!! Should not be shown !!!" showon="controller2:1[AND]nonexistent:2" />
<field name="dependent06" type="text" label="Dependent Field 06" default="!!! Should not be shown !!!" showon="nonexistent:2[AND]controller2:1" />
<field name="dependent07" type="text" label="Dependent Field 07" default="!!! Should be shown !!!" showon="nonexistent:2[OR]controller2:1" />
<field name="dependent08" type="text" label="Dependent Field 08" default="!!! Should be shown !!!" showon="controller2:1[OR]nonexistent:2" />
<field name="dependent09" type="text" label="Dependent Field 09" default="!!! Should be shown !!!" showon="controller2:1[OR]controller2:1" />
I have tested this item ✅ successfully on 45133c8
The field was gone
I did check again with npm ci and showon.min.js was changed.
This time the field vanished as expected.
The above test cases in *.xml worked before the patch and afterwards.
I may be on the wrong path here ;-)
This comment was created with the J!Tracker Application at issues.joomla.org/tracker/joomla-cms/46488.
Hello @coolcat-creations
we discussed it in maintainer and we all agreed, that a false showon configuration should not break the page. We identified one thing, which you please could add to your PR:
This PR "hides" a miss-configuration of the system, so we thought that the site owner should be informed about the issue in some way, either here in the JS code with a console log message or in the backend inside the field, that the showOn is broken (or both, but happy with one). Could you please add this somehow? Thank you in advance.
That's a good idea too. So instead of showing the field, I will write into console "hidden because showon condition is invalid" ? is that ok?
That's a good idea too. So instead of showing the field, I will write into console "hidden because showon condition is invalid" ? is that ok? @bembelimen
Yes, your code + the extra comment
| Labels |
Added:
NPM Resource Changed
bug
PR-5.4-dev
|
||
@bembelimen ok, done - can someone retest?
Warning in console:
shouldnt that warning be translatable?
Somehow, information seems to have been lost along the way to @bembelimen . We agreed in the maintainer team that a warning would definitely be useful.
Thank you for the effort you are putting into improving things here.
The potential problem here arises at the latest when showon is used with a negative condition. Then, unfortunately, the code may have exactly the opposite effect to what you want to achieve and lead to even more confusion.
In the core itself, it should probably remain a simple warning and dispatching the event so that even less experienced users or developers can quickly become aware of the problem and recognise their misconfiguration or bug in their xml.
However, if you keep the event in there, you can then add an Eventlistener and hide it in according to your specific needs.
Let’s use an example:
I have custom fields set up like this: one field is Branches (e.g. “restaurants”), and a dependent “subfield” lists different cuisines and is configured with showon = branches:restaurants.
If Branches is deleted, doesn’t exist, or is unpublished, the cuisines field is currently still shown. That’s incorrect, because the showon condition can’t be met in that case. The cuisines field should definitely be hidden.
Yes, it really isn't easy, I understand what you mean.
I'll give it a try with your example.
If you have the opposite case and, for example, you have the cuisine field for all of them and only have one branch to which this does not apply.
showon = branches:!retail
Then you may eventually realise that retail simply does not suit your target group and delete the Branches field completely because you no longer need the information.
Then the cuisine field would never be shown, even though there is a greater potential here that it should be displayed. And by the time you notice, you have potential "data loss" because you will not fill in a field that you cannot see.
What we are actually missing in the custom field case is validation at the field configuration level in the backend to catch the underlying issue. But I don't see that within the scope of this PR.
If Branches is deleted, doesn’t exist, or is unpublished, the cuisines field is currently still shown. That’s incorrect, because the showon condition can’t be met in that case. The cuisines field should definitely be hidden.
This is misconfiguration can lead to even more confusion.
For example you have 50+ fields. After some time you delete Branches field and the cuisine field become always hidden. You forget cuisine field even exists because it is not visible.
This is argument not to hide the field because it will hide bugs in User's setup.
showon = branches:!retail
The change only hides when the trigger field itself isn’t found no input/select named branches (or branches[]) was
located, so origin.length === 0.
For your example showon="branches:!retail" specifically:
-
If the branches field exists: the showon logic runs; the field is shown for any value except retail, and hidden only when the value is retail.
-
If the branches field does not exist in the DOM: the dependent field is immediately hidden and a console warning is logged.
-
The presence/absence of a retail option/value alone doesn’t trigger the line 89 hide; it just means the != retail condition will always evaluate as “show”.
If the trigger truly isn’t present in the form, hiding is intentional to flag an invalid showon setup.
- If the trigger truly isn’t present in the form, hiding is intentional to flag an invalid showon setup.
how would you know then the setup is invalid... ? I think Warnings in the console could be really helpful.
how would you know then the setup is invalid... ? I think Warnings in the console could be really helpful.
Yes, absolutely, and that's why we're very grateful to you for your improvement. The only thing we don't want is what Fedik already mentioned.
... not to hide the field because it will hide bugs in User's setup.
However, since the event you originally implemented is still there, you can use this event for example, in your template user.js with an eventlistener. Thanks to the flag suggested by Fedik, you know that it was triggered in this context and can then simply hide the field.
This is a decision that the user should make consciously.
see suggested change: #46488 (comment)
The core should not mask issues or misconfiguration and thus make debugging more difficult.
@LadySolveig ok I committed the suggestion, that should be it, or do you want me to remove the console warning too?
@coolcat-creations It seems the js has a syntax error now: https://github.com/joomla/joomla-cms/actions/runs/20110068783/job/57704740967?pr=46488
Thank you @dgrammatiko @LadySolveig @Fedik @richard67 @bembelimen
@LadySolveig anything to do for me from my side?
No, not from my side. Everything seems to be as it should be now. @richard67 @muhme
No, not from my side. Everything seems to be as it should be now. @richard67 @muhme
@LadySolveig As usual, the PR needs 2 successful human tests after it has been changed. Nothing RMs can do here before there are 2 tests.
Just FYI, that in my opinion would be ready to test. But as you mentioned, I'm not the RM. :)
Does this respect the [AND] and [OR] Operators?