Problem/Motivation

When a vertical tab pane shares a similar ID prefix as a different Details element, then the webform save logic stops the vertical tabs from working as it conflicts with how Drupal original hides certain DOM elements required to reexpand the element.

Ran into this while testing my theme with https://www.drupal.org/project/styleguide, which happened to also have a Webform in its footer region. Collapsing a different fieldset stops the vertical tabs from working after refreshing the page (since they share a similar ID prefix).

Steps to reproduce

  1. Create and add a webform with the details save functionality
  2. Create a fieldset and a vertical tab pane sharing an ID prefix
  3. Collapse the normal fieldset
  4. Refresh, and the tab pane will no longer be able to open

Proposed resolution

Update Drupal.webformDetailsSaveGetName to ignore if the element is a vertical tab pane:

    if ($details.hasClass('vertical-tabs__pane')) {
      // Vertical tab states can't be saved.
      return '';
    }

Remaining tasks

User interface changes

N/A

API changes

N/A

Data model changes

N/A

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

codebymikey created an issue. See original summary.

jrockowitz’s picture

This issue seems like an edge case that can be resolved by adding the [data-webform-details-nosave] attribute to vertical tabs details pane. I am not sure I want to add .vertical-tabs__pane detection to the webform's details save code.

  • a1d3cc5 committed on 3182414-vertical-tabs
    Issue #3182414: Details save functionality is incompatible with Vertical...

  • 09796b0 committed on 3182414-vertical-tabs
    Issue #3182414: Details save functionality is incompatible with Vertical...

  • 1d3ec91 committed on 3182414-vertical-tabs
    Issue #3182414: Details save functionality is incompatible with Vertical...
jrockowitz’s picture

Status: Active » Needs review
FileSize
13.34 KB

I started to investigate this issue and decided to add very basic hidden support for vertical tabs. Generally, I don't see a use case for fully supporting vertical tabs but it is possible for someone to create them via the YAML source. For example, site builders would have to manually add the #group attribute to the fieldset or details elements.

  • 30e4552 committed on 3182414-vertical-tabs
    Issue #3182414: Details save functionality is incompatible with Vertical...
jrockowitz’s picture

  • 3599117 committed on 3182414-vertical-tabs
    Issue #3182414: Details save functionality is incompatible with Vertical...

  • jrockowitz authored 34a9557 on 8.x-5.x
    Issue #3182414 by jrockowitz: Details save functionality is incompatible...
jrockowitz’s picture

Status: Needs review » Fixed

I committed the patch. Please download the latest dev release to review.

  • jrockowitz authored 34a9557 on 6.x
    Issue #3182414 by jrockowitz: Details save functionality is incompatible...
codebymikey’s picture

Again, really appreciate the quick turnaround for addressing these issues. The latest dev version addresses the issue for me.

This issue seems like an edge case that can be resolved by adding the [data-webform-details-nosave] attribute to vertical tabs details pane.

That's what I initially thought as well, and was going to submit a patch to Styleguide addressing the webform compatibility issue for those who might need it. But on further investigation, wouldn't work because the data-webform-details-nosave attribute check is only used on the fieldset summary "onclick" event, which Drupal's vertical tabs don't trigger as it uses a hide/show to show the child fieldsets instead.

So it made more sense to address the issue here since the behaviour was related to how the unique ID logic was being resolved for elements with incrementing IDs like edit-details-open--1, edit-details-open--2 etc. where they happen to share the same property name like Styleguide did.

Rather than patching Styleguide or changing the ID code to try and detect incrementing IDs (which might be its own bug/feature request in the future), it seemed like there was an incompatibility issue with vertical fieldsets and would made sense to just ensure that vertical tabs weren't affected since they fundamentally couldn't/shouldn't ever be collapsed.

I guess the core issue is that the webform.element.details.save.js script is manipulating fieldsets that were not defined by Webform. I don't really mind though as developers who don't want the save functionality can simply disable it or patch the code to not rely on the IDs and work solely off the data-webform-element-id attribute.

jrockowitz’s picture

...it seemed like there was an incompatibility issue with vertical fieldsets and would made sense to just ensure that vertical tabs weren't affected since they fundamentally couldn't/shouldn't ever be collapsed.

This is exactly why I added "hidden" support for Vertical tabs to ensure compatibility even though no one would want to use Vertical tabs in a webform.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.