🇫🇮Finland @Tuuuukka

MR 623 seems to fix the issue nicely. What about the failing PHPUnit test (https://git.drupalcode.org/project/webform/-/jobs/4876195#L713) though?

tuuuukka → created an issue.

tuuuukka → created an issue.

Not sure if this helps, but for me is throws an error in console and refuses to update related variable in the local browser storage

Which browser did you get this in @euk? I had nothing in console when I worked on this.

Been investigating this a bit and not going in to too much details, the issue is related to the ResizeObserver and it being run in certain scenarios. That leads to the sidebar opening, the height of the html element changing, thus handleResize() being run and sidebar being closed again by it. You can see this happening with e.g. this:

diff --git a/js/sidebar.js b/js/sidebar.js
index 9fd9411c..a275864e 100644
--- a/js/sidebar.js
+++ b/js/sidebar.js
@@ -84,6 +84,7 @@
     },
 
     showSidebar: () => {
+      console.log('open')
       const chooseStorage = window.innerWidth < breakpoint ? storageMobile : storageDesktop;
       const hideLabel = Drupal.t('Hide sidebar panel');
       const sidebarTrigger = document.querySelector('.meta-sidebar__trigger');
@@ -114,6 +115,7 @@
     },
 
     collapseSidebar: () => {
+      console.log('close')
       const chooseStorage = window.innerWidth < breakpoint ? storageMobile : storageDesktop;
       const showLabel = Drupal.t('Show sidebar panel');
       const sidebarTrigger = document.querySelector('.meta-sidebar__trigger');
@@ -133,6 +135,7 @@
     },
 
     handleResize: (windowSize = window) => {
+      console.log('resize')
       Drupal.ginSidebar.removeInlineStyles();
 
       // If small viewport, always collapse sidebar.

In the scenario described in the issue and in #3, when trying to open the sidebar this will log:

open
resize
close
resize
close

In a normal/working situation, i.e. in other viewport widths/heights, it will just log "open". As said before, the issue is that the height of the html element changes and the functionality in handleResize() will then close the sidebar, thus the user will never see it.

I opened an MR to demonstrate how this could be tackled. The idea is that handleResize() is called only if the width of the html element changes. I don't think the height matters or is used in any way there. See the changes: https://git.drupalcode.org/issue/gin-3506018/-/compare/4.0.x...3506018-s....

Other ways to solve this are welcomed of course.

Looks like there was no scrollbar in the browser window in your test @sandip-poddar, and indeed it seems to work if scrollbar is missing.

Here's another video where you can see that when I have "device type" set to "desktop", scrollbar is present and sidebar is not working. But then when I change the device type to "mobile" and the scrollbar is gone, sidebar works normally.

So it's not actually just about the viewport size, but the presence of scrollbar in these specific sizes.

Can you try again if it acts like this for you too?

tuuuukka → created an issue.

#21 if you're sure it's been fixed, this issue status can be set to fixed or closed..?

When you submit the checkboxes widget with only disabled options checked, the value callback function gets nothing for input. If you check/select an enabled option too, the disabled ones keep their values also.

The input is checked here: https://git.drupalcode.org/project/drupal/-/blob/11.x/core/lib/Drupal/Co.... As stated, with only disabled options checked, the $input variable is empty, so it defaults to using $element['#default_value'], but that's empty too, so it all ends up returning an empty array.

tuuuukka → changed the visibility of the branch more-actions-multiple-click to hidden.

tuuuukka → created an issue.

RTBC +1

Here's the correct patch file which includes nothing but the JS fix from #2.

#2 seems to fix it, nice work mdolnik.

To keep things simple and just fix the issue that's mentioned in the original post, I'd leave the versioning out of the patch though. The versioning could be done as a separate issue/PR/patch.

Could this work? It clears the deleted field's config from config/sync/diff.plugins.yml when the field is deleted.

To test:

1. Add a new field to e.g. a content type.
2. Run drush cex and make sure you see the field in config/sync/diff.plugins.yml.
3. Delete the field.
4. Run drush cex again and make sure the field's not there anymore.

#2 fixed it for us, thanks!

Tuuuukka → created an issue.

Tuuuukka → created an issue.