Widget parameter depends does not work on specified block

[LordHansolo]

Preconditions

1. Magento 2.1.1

Steps to reproduce

1. Create Module adding Custom Widget
2. Add Parameter like <parameter name="catalog_url" xsi:type="block" visible="true" required="true" sort_order="33"> <label translate="true">Category</label> <depends> <parameter name="enable_url" value="1" /> <parameter name="target_url" value="1" /> </depends> <block class="Magento\Catalog\Block\Adminhtml\Category\Widget\Chooser"> <data> <item name="button" xsi:type="array"> <item name="open" xsi:type="string" translate="true">Select Category...</item> </item> </data> </block> </parameter>
   
   It is important to use block class="Magento\Catalog\Block\Adminhtml\Category\Widget\Chooser" or block class="Magento\Catalog\Block\Adminhtml\Product\Widget\Chooser".
3. Set any custom depends.
4. Go to admin panel. Add your widget. In widget options change parameter that our parameter depends on.

Expected result

Our Parameter disappears, if conditions set on depends are not met.

Actual result

Parameter is visible anyway.

[biolauri]

It's also an issue in Magento 2.1.2. And, in my opinion, it is not important which block class you use, as this is a general issue with all parameters of xsi:type="block" depending on another parameter.

In #5443, you find detailed info of the expected/actual for the problem (display:none; is set on the wrong html element). I can confirm that these are the same for this one!
Maybe, this is a duplicate of #5443 (but the steps to reproduce are a bit different).

[magento-engcom-team]

@LordHansolo, thank you for your report.
We've created internal ticket(s) MAGETWO-82054 to track progress on the issue.

[henk-hypershop]

What will be the expected fix timeframe? It is quite confusing that all depend labels are still shown.

[VincentMarmiesse]

Hello,
Any news on this issue?

[maartenwolfsen]

In my case, the problem was that the selected rowElement was the child of the rowElement that was supposed to be hidden. I added the following piece of code to fix this to
lib/web/mage/adminhtml/form.js line 567:

if (rowElement.className === 'admin__field-control control') {
rowElement = target.up(2);
}

I am currently looking for a better solution.

[m2-assistant]

Hi @sergey-solo. Thank you for working on this issue.
Looks like this issue is already verified and confirmed. But if you want to validate it one more time, please, go though the following instruction:

• 1. Add/Edit Component: XXXXX label(s) to the ticket, indicating the components it may be related to.

• 2. Verify that the issue is reproducible on 2.3-develop branch

  Details

  - Add the comment @magento give me 2.3-develop instance to deploy test instance on Magento infrastructure.
  - If the issue is reproducible on 2.3-develop branch, please, add the label Reproduced on 2.3.x.
  - If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!

• 3. If the issue is not relevant or is not reproducible any more, feel free to close it.

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[OvalMedia]

For the impatient here is a fix: https://magento.stackexchange.com/questions/176091/magento-2-depends-is-not-working-in-widget-xml. Make sure you consider the first comment as the require-config.js is placed in the wrong directory. I can confirm it works fine on 2.2.9.

[koenner01]

I can confirm this issue is still present in 2.3.3.

Fix from @OvalMedia works but I really don't like copying a gigantic javascript and appending 3 lines. This is not very future (= maintainable) proof.

[hostep]

Here's a solution which seems to work in our case, it's strongly based on the stackexchange proposal but drops the original PrototypeJS implementation and uses jQuery all the way now: #30570

[magento-engcom-team]

Hi @LordHansolo. Thank you for your report.
The issue has been fixed in #30570 by @hostep in 2.4-develop branch
Related commit(s):

• e3789f0906f45b565fdb8d13d28c305917cca1bd

The fix will be available with the upcoming 2.4.2 release.

[DmitryFurs]

@magento-engcom-team @sidolov @ihor-sviziev the corresponding pull request is merged, but the fix does not cover all possible cases. 2 additional cases are described in the comments to the pull request #30570