[5.4] Fix: Showon fails open when source field does not exist (hidden by default instead) #46488

coolcat-creations · 2025-11-24T12:31:59Z

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.

chmst · 2025-11-24T13:02:03Z

Does this respect the [AND] and [OR] Operators?

coolcat-creations · 2025-11-24T13:20:54Z

Yes, when the second condition is not applicable, the field is hidden. ( I described it in the test instructions)

ThomasFinnern · 2025-11-29T20:11:44Z

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.}

coolcat-creations · 2025-11-30T12:22:36Z

@ThomasFinnern changed, thank you - did you test it?

ThomasFinnern · 2025-11-30T14:17:12Z

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" />

ThomasFinnern · 2025-11-30T14:40:51Z

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.}

bembelimen · 2025-12-04T09:50:10Z

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.

coolcat-creations · 2025-12-04T12:32:39Z

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

bembelimen · 2025-12-04T17:41:39Z

Yes, your code + the extra comment

coolcat-creations · 2025-12-05T12:16:56Z

@bembelimen ok, done - can someone retest?
Warning in console:

brianteeman · 2025-12-05T12:18:27Z

shouldnt that warning be translatable?

LadySolveig · 2025-12-05T14:35:53Z

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.

LadySolveig · 2025-12-05T15:16:01Z

build/media_source/system/js/showon.es6.js

+            field.classList.add('hidden');
+            field.dispatchEvent(new CustomEvent('joomla:showon-hide', {
+              bubbles: true,
+            }));


Suggested change

field.classList.add('hidden');

field.dispatchEvent(new CustomEvent('joomla:showon-hide', {

bubbles: true,

}));

field.dispatchEvent(new CustomEvent('joomla:showon-hide', {

detail: {reason: 'missingParent'}

bubbles: true,

}));

Just a suggestion.
Related comment: #46488 (comment)
What do you think, @Fedik @dgrammatiko would it make sense to have a separate event here?

I would keep it minimal. Without extra events.
If you really need to have some flag about missing parent then can do kind of:

field.dispatchEvent(new CustomEvent('joomla:showon-hide', { detail: {missingParent: true} bubbles: true, }));

Or:

detail: {reason: 'missingParent'}

Nice thanks for the suggestion.

You would then leave field.classList.add(“hidden”); in place?
Even if that means that in a condition such as, for example, foo!: or foo!:1 are we more likely risk the undesirable side effect of data loss until the user notices it?

Otherwise, I find the event name somewhat confusing.

I don't think it will ever fit in any direction anyway. The main question is in which direction it could potentially cause more problems. 🙃

Personalty I would not hide the field, only show the warning about misconfiguration.
But if people want we can hide.

There should not be any data lose because it just visual thing and nothing to do with field values.

Just wasn't sure if I had understood you correctly, but that basically confirms what we discussed earlier.

coolcat-creations · 2025-12-05T16:43:34Z

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.

LadySolveig · 2025-12-05T16:55:40Z

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.

Fedik · 2025-12-05T20:10:19Z

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.

coolcat-creations · 2025-12-05T20:13:59Z

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.

coolcat-creations · 2025-12-05T20:16:22Z

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.

LadySolveig · 2025-12-05T20:23:23Z

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.

LadySolveig · 2025-12-05T20:34:44Z

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.

Fix Showon Behaviour when "parent field" is missing.

45133c8

joomla-cms-bot added NPM Resource Changed This Pull Request can't be tested by Patchtester PR-5.4-dev labels Nov 24, 2025

HLeithner changed the title ~~Fix: Showon fails open when source field does not exist (hidden by default instead)~~ [5.4] Fix: Showon fails open when source field does not exist (hidden by default instead) Nov 24, 2025

richard67 added the bug label Nov 25, 2025

Add Console Warning for Administrators

61720de

LadySolveig reviewed Dec 5, 2025

View reviewed changes

Uh oh!

[5.4] Fix: Showon fails open when source field does not exist (hidden by default instead) #46488

Are you sure you want to change the base?

[5.4] Fix: Showon fails open when source field does not exist (hidden by default instead) #46488

Uh oh!

Conversation

coolcat-creations commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

chmst commented Nov 24, 2025

Uh oh!

coolcat-creations commented Nov 24, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

ThomasFinnern commented Nov 29, 2025

Uh oh!

coolcat-creations commented Nov 30, 2025

Uh oh!

ThomasFinnern commented Nov 30, 2025

Uh oh!

ThomasFinnern commented Nov 30, 2025

Uh oh!

bembelimen commented Dec 4, 2025

Uh oh!

coolcat-creations commented Dec 4, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

bembelimen commented Dec 4, 2025

Uh oh!

coolcat-creations commented Dec 5, 2025

Uh oh!

brianteeman commented Dec 5, 2025

Uh oh!

LadySolveig commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

LadySolveig Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Fedik Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

LadySolveig Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

Fedik Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

LadySolveig Dec 5, 2025

Choose a reason for hiding this comment

Uh oh!

coolcat-creations commented Dec 5, 2025

Uh oh!

LadySolveig commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Fedik commented Dec 5, 2025 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

coolcat-creations commented Dec 5, 2025

Uh oh!

coolcat-creations commented Dec 5, 2025

Uh oh!

LadySolveig commented Dec 5, 2025

Uh oh!

LadySolveig commented Dec 5, 2025

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

9 participants

coolcat-creations commented Nov 24, 2025 •

edited

Loading

coolcat-creations commented Nov 24, 2025 •

edited

Loading

coolcat-creations commented Dec 4, 2025 •

edited

Loading

LadySolveig commented Dec 5, 2025 •

edited

Loading

LadySolveig Dec 5, 2025 •

edited

Loading

LadySolveig commented Dec 5, 2025 •

edited

Loading

Fedik commented Dec 5, 2025 •

edited

Loading