Fix HTML5 validation prevents submission in tabs

tested. It works actually. Thanks!

Hi,

This patch doesn't work on image alt field. Console shows: "An invalid form control with name='field_image[0][alt]' is not focusable." error.

Patch worked for me including on image ALT fields.

Adding a related core issue. Note that HTML5 validation has severe accessibility problems in most (all?) major browsers supported by Drupal.

Small update to the patch in #3. The logic should not be executed on submit buttons with a formnovalidate attribute.

This was causing issues for me with Entity Browser in combination with Field Group vertical tabs. When clicking the Entity Browser open modal button, the first vertical tab (with a required field) would automatically open.

Interesting approach, will test this.

Awesome. Thanks. Will continue testing.

Patch in #9 works great for me in testing and is a huge usability win. Thanks @chris-happy, @rp7 and @julien!

The patch in #9 is idd already a huge usability win, but does not cover yet all the cases. It still goes wrong if you have nested tabs.
Example:
- Tab 1: text field
- Tab 2: paragraph with
-- Tab 1: Image
-- Tab 2: Required text field

When you are on tab 1, you are not jumping to the second tab.

D8.8.5, FG8.x-3.0
patch #9 doesn't work for me:
-error on tab A (closed), user is on tab B (open) and tries to submit. Nothing happens (can't submit and no error message).

As mentioned in earlier comments this javascript doesn't work with nested tabs such as when the required field is inside a vertical tab that's inside a horizontal tab. The vertical tab ends up being targeted and so the horizontal tab is never auto-clicked.

Just for clarification: I applied the patch and it does work in such a way that the first tab which contains a required field is opened and Chrome can add its tooltip. However, there are still error messages like "An invalid form control with name='field_required_text' is not focusable." in the console which do refer to required fields in other tabs.

Am I correct to assume, that this behaviour can't be fixed with a patch as it is part of Chrome?

That's Chrome identifying a likely patchable problem: I wouldn't disregard it.

In my testing, the patch didn't work, because $(this).closest('.field-group-tab').attr('id') returned nothing.
I was able to get things to work adding the classes I saw created with both horizontal and vertical tabs:
$(this).closest('.field-group-tab, .horizontal-tabs-pane, .vertical-tabs__pane').attr('id')

The patch in #9 doesn't always work because it only loops required fields. However, if you have validation on a non-required field (such as an input type number which validates whole integers), the tab does not receive focus. I've rerolled a patch which checks all form elements, instead of only required ones.

Patch works great. Not sure if Drupal coding standards allow inline comments on the same line as the code?

Patch #19 is working for me and it is very useful. Thanks!

#19 works perfectly, but when there is an input within a subset of tabs, this solution does not reach that depth.

Let me explain:

For this one it does work:

However, for a sub-level of eyelashes, it fails to reach:

I had the validation problem on a vertical tabs set up and I can confirm that patch #19 works in my case.

I can also confirm that patch from #19 works as expected – thanks for this one!

Confirming that path #19 works.

Confirming that path #19 works for vertical tabs, thank you.

Using #1797438: HTML5 validation is preventing form submit and not fully accessible patch for the Drupal core
Or #2969051: Fix HTML5 validation prevents submission in tabs

Confirming that patch #19 works as expected. This is ready to be merged in the module.

Confirming that patch #19 works.

Patch works and is very helpful.

We just had a console log error when adding values in a nested form (media reference field):
Uncaught TypeError: Cannot read property 'elements' of undefined

Making sure that $form[0] is not undefined fixed it.

Patch works as expected. Thank you!

Hi it works partially for me.

It's not working in forms of the bibcite module.
The module overrides the form display programmatically.
Maybe something is missing in the override? The tabs aren't marked as required.

Patch #9 does not work with the Gin theme.

#31 works with Claro theme

The current patch is not working with the Gin theme where the Submit button is in a different region. I've added a layer for this, but it would be great if someone could take a look at it again.

The new patch continues to work nicely in Claro.

The code looks fine to me if we're not picky about Drupal code standards. Otherwise I'd say put all those inline comments on the line about the code they're describing. But as they already passed review I won't hold back RTBC based on that.

1. +++ b/formatters/tabs/tabs.js
   @@ -43,4 +43,33 @@
   +      if (typeof $('<input>')[0].checkValidity == 'function') { // Check if browser supports HTML5 validation
   +        $('.form-submit:not([formnovalidate])').once('showTabWithError').on('click', function() { // Can't use .submit() because HTML validation prevents it from running
   ...
   +              if (this.checkValidity && !this.checkValidity()) { // First check for details element
   +                var id = $(this).closest('.field-group-tab').attr('id'); // Get wrapper's id
   +                $('[href="#' + id + '"]').click(); // Click menu item with id
   +                return false; // Break loop after first error
   

   nit: these comments should be on the line above

2. +++ b/formatters/tabs/tabs.js
   @@ -43,4 +43,33 @@
   +          var $this = $(this),
   ...
   +            let $header = $this.closest('header');
   

   there's a mix of var and let here.

   for this to work on IE11, we'd need just var

3. +++ b/formatters/tabs/tabs.js
   @@ -43,4 +43,33 @@
   +          // Support themes where the submit button is separated from the form like the Gin theme.
   

   nit: >80 chars here

This patch addresses the comments in #38 and #39, but also checks if the invalid input is actually inside a tab before attempting to switch tabs. It also calls Drupal.FieldGroup.setGroupWithfocus($tab) instead of attempting to click on the matching tab link.

Setting to needs work since we ought to write a test for this.

• Added a test
• Fixed whitespace issues
• Uploaded a test-only patch

#40: Awesome, I did wonder about using .click() there but I guess I got lazy in reviewing that bit.

So with that in mind, while I do think this is RTBC, this would normally be frowned upon unless the test was breaking right? (did it break the test?):

1. +++ b/tests/src/Functional/FieldGroupTestTrait.php
   @@ -30,7 +30,7 @@ trait FieldGroupTestTrait {
   -    $data['format_settings'] += Drupal::service('plugin.manager.field_group.formatters')->getDefaultSettings($data['format_type'], $context);
   +    $data['format_settings'] += \Drupal::service('plugin.manager.field_group.formatters')->getDefaultSettings($data['format_type'], $context);
   

   Unrelated change.

That said, I really don't think it's worth splitting off, so, having installed this patch and tried it out, reviewed the code again and the new test I'm going to call this RTBC again.

@darvanen might have been related to my local environment, maybe it's a php8 thing, but yeah it didn't work without the extra \.

Removing unused use statements as per testbot results.

#43: Does seem like a php 8 thing, thanks for the response :)

#44: Oops! Missed those, thanks.

I see nothing else outstanding, back to RTBC.

+++ b/formatters/tabs/tabs.js
@@ -39,8 +39,54 @@
+          // Set focus to the first invalid tab.
+          var $tab = $(this).closest('.field-group-tab');

Excuse my lack of understanding here, but how does this limit it to only invalid tabs?

Cross post, sorry for the unintended status change

@larowlan We loop through every element in form. The first invalid element is caught by !this.checkValidity(). If it is not inside a .field-group-tab we continue and let the browser handle it normally. For example a title field that appears above the tabs. Otherwise if the first invalid element is inside a tab we switch to that tab then let the browser handle it from there.

Ah! that was the bit I didn't understand, thanks for explaining ❤️

I'm stuck on a SaaS installation that doesn't allow patching, so this is my workaround until this patch is incorporated and the module updated in our SaaS profile.

This JS code lives in an Adminimal subtheme:

// Check for Chrome
// https://stackoverflow.com/questions/4565112/javascript-how-to-find-out-if-the-user-browser-is-chrome#answer-13348618
function chromeDesktop() {
    var isChromium = window.chrome,
        winNav = window.navigator,
        vendorName = winNav.vendor,
        isOpera = typeof window.opr !== "undefined",
        isIEedge = winNav.userAgent.indexOf("Edg") > -1,
        isIOSChrome = winNav.userAgent.match("CriOS");

    if (isIOSChrome) {
        // is Google Chrome on IOS
    } else if (isChromium !== null &&
        typeof isChromium !== "undefined" &&
        vendorName === "Google Inc." &&
        isOpera === false &&
        isIEedge === false) {
        // is Google Chrome
        return true
    } else {
        // not Google Chrome
        return false
    }
} // End checkBrowser()

function analyzeFieldVisiblity(field) {
    if (chromeDesktop() === true) {
        // Check element visibility
        if (field.offsetWidth === 0 || field.offsetHeight === 0) {
            if (field.hasAttribute('required')) {
                field.removeAttribute('required');
                // Add a targeting class so we can re-add the attribute if the element is visible next time the user submits the form
                field.classList.add('required-removed');
            }
        } else {
            if (field.classList.contains('required-removed')) {
                field.setAttribute('required', 'required');
            }
        }
    }
} // End analyzeFieldVisiblity()

Same problem and solution can be applied to accordian.

Patch in #44 fixes tabs only. Patch in #51 fixes accordions only and has no tests. We need a combined patch or to limit the scope.

The patch in #44 works for me when I have fields in tabs. However, when I use paragraphs within those tabs, nothing happens. I suspect it's because the fields are located on a deeper level.

I used #44 as well (and it worked), however when adding a Paragraph on the active tab using the modal "Add mode" and there's a required (but empty) field on an inactive tab, after you add the paragraph , it automatically takes you to the empty field (on the other/inactive tab) without giving any indication as to why. (i.e. there's no "please fill out this field").

The patch in #44 partially fixes the issue. It works fine when we have some tab groups inside tabs but only upto one level. As per #13, #15, #23, #53, #54, I was also able to reproduce the same. Whenever we are nesting tab elements, the same problem pops up.

The problem is previous patches were only trying to focus directly on the error field but when we have nested tabs, the focus should trigger respectively down from parent to children to render the field back in display.

Also #51 should be handled in a new issue queue as that patch for accordion should also have the same problem. Will create a new issue after this.

Apologies. Pushed wrong patch file.

I can see in the output of running test cases, there are 2 errors although they are not regarding the changes made in this patch, seems like existing issues. Here I am adding the patch to fix one of the errors which is in MigrateUiFieldGroupTest.

The other issue occurring in EntityDisplayTest is about adding support for #description_display. I also found an issue already raised for that in https://www.drupal.org/project/field_group/issues/3205504 and it seems to be handled in there. Ignoring it for the same.

Created new issue for accordion following #51, #52 and #55
https://www.drupal.org/project/field_group/issues/3292650

+++ b/contrib/field_group_migrate/tests/src/Functional/MigrateUiFieldGroupTest.php
@@ -119,7 +119,6 @@ class MigrateUiFieldGroupTest extends MigrateUpgradeTestBase {
-    $connection_options['prefix'] = $connection_options['prefix']['default'];

Where did this come from? It's not part of the field_group module...

Suggest re-posting #56.

@darvanen I added that as a fix for the tests failure. Check the test results of #56.

That failure is happening in HEAD along with several others. We'll need to ignore test failures until such a time as HEAD is passing.

What follows is a review of #56.

+++ b/formatters/tabs/tabs.js
@@ -44,8 +44,71 @@
+          Object.keys($allParents).forEach(function(key) {
+            if (key !== 'length' && key !== 'prevObject') {
+              // jQuery .parents() returns parent elements from innermost to
+              // outermost matches. We need to focus in reverse order to
+              // bring the element in view.
+              var element = $allParents[$allParents.length - 1 - parseInt(key)];
+              Drupal.FieldGroup.setGroupWithfocus($(element));
+              var parentDirection = $(element).hasClass('vertical-tabs__pane') ? 'vertical' : 'horizontal';
+              $(element).data(parentDirection + 'Tab').focus();
+            }
+          });

This function is only using the forEach loop as a counter instead of an iterator. Instead of using indexes and math to 'focus in reverse', just reverse() the array before processing it with forEach().

Reroll of #59 without the rejected adjustments to tests as #44 is no longer applying, at least for me.

I tried acting on my review in #64 and have realised I was wrong. I still think there must be a better way to do it but I don't have the time for that right now so I'm just uploading the reroll for anyone who needs it.

Adding patch.

Added Gin/Claro theme support to the #19 patch

Hello,

I've had the same problem with detail group.

I have adaptated the #71 patch for this.

However, it's doesn't work if the detail group is inside an another closed group too.

Should do the job for all group types and consider group encapsulation ?

Hello,

Sorry for the duplicate comment, I rename my patch with Drupal standard.

FYI I followed the steps in the issue summary.

And was not able to replicate in Google chrome on the latest version of field_group.

Could we get an updated issue summary

I can reproduce in both Firefox and Chrome with the updated steps to reproduce.

#71 works. Thank you!

I could still reproduce the issue with the latest version o field_group and the patch from #73 does solve my issue.

Make sure you clear the caches and browser cache when you are validating the patches ;)

#71 works. Using gin theme 3.0.0-beta5, with fields nested under vertical tabs.

#71: gin/claro support was already in #69, I do not understand why you restarted from #19? By doing so you miss out on a lot of the work that resulted from discussions after #19, including the test. Marking NW due to this.

#72/#73 that's a good start, I think it will need tests if you want the maintainers to commit it. Perhaps if you're going to create a different set of work you could open a related issue to track it?

Here's a patch that passes locally. The logic in the test was flawed, I updated it to match the expected behaviour.

As this passed locally I think the chromedriver might be a bit slower in the core test runner. Added a small wait to ensure enough time passes to let the tabs switch.

Forgot to mention: I did notice #71 had a slightly more elegant (in my opinion) way of supporting gin/claro so I switched to using that over the one in #69 as can be seen in the interdiff of #80.

One more try with the default 10 second timeout in place on the wait.

Updated the use of 'once' for Drupal 10.

Patch works well for me on field_group 3.4 + D9.4 and the same issue as seen in the opening post. On validation fail, a relevant tab with an empty mandatory field is opened and the field shown as failing validation.

Tested the issue on Drupal 9.5.x-dev and 10.1.x-dev.
Able to reproduce the issue.
Applied the patch on both the versions
The patch applied cleanly on both.

The patch works fine. The error message is now displaying on the relevant tab after applying the patch.
Refer to the attached screenshot and the video
Before patch:

After patch:
Refer to the attached video - tabs_10-1-x-dev-after-patch.mp4

RTBC+1

The #87 patch applies cleanly and does what it has to do. The inactive tab gets opened and shows the required field that was left empty.

I'm finding the #87 patch works, but I am still seeing the error in the console. Since an earlier patch I've used (#71) got rid of the console error, I was not expecting to see it.

Hi All,

I'm reopening this since it still an issue when using the Multistep option. We have a contentype with 3 multi-groups under this scenario but unfortunately after upgrading to x.3.4 - D9.5 they stop working on the Admin side (not even user 1 can create content). I've applied the patch on #87 successfully but the issue persists, I have also disabled the HTML5 validation on ALL forms $form['#attributes']['novalidate'] = 'novalidate'; on a custom module. There are no permission implemented, as i mentioned not even user 1 can go through the second step (we have 3 steps using field group ) Works OK on the front end theme. Gin works ok for other contentypes without Field Group. Dont see any Javascript errors on console or any other php errors either.

Personally I would prefer that different group types had separate issues per #53.

Patch #87 doesn't work when the form is rendered via ajax.

context should be removed from selector.

$(once('showTabWithError', '.form-submit:not([formnovalidate])')).on('click', function(e) {

I have updated sector and hv re-rolled patch #87.

FWIW a similar problem was fixed in core for vertical tabs. See #2911932: Correct vertical tab does not focus on form validation

Latest patch seems to have no effect in Gin and Field Group in Drupal 10.

The latest patch works for me with tabs on Gin in Drupal 9. Thanks a lot for the huge improvement.

The last 2 comments are saying the opposite... could we maybe get more elaboration on #103? I'm using this patch with Claro and it is resolving this issue, so I'm going to put to RTBC, but with the caveat that I'm not testing in Gin and 103/104 are saying it's working/it's not.

@kevinquillen & @ayalon what's true for Gin? (#103 vs. #104)
It it worth a contrib test with gin as test_dependency to be 100% sure?

Could this please use a MR instead of further patches?

I've tested the patch in #100 with Drupal 10.1.5 and GIN 3.0.0-rc7. It resolves the issue for me.

@Anybody
Created a MR

- Changing to Needs review

works for me in drupal 9.5 will this be in the latest version of the module soon?

Latest patch works well for me, Drupal 9.5.9 and Field Group 3.4.0.

Patch #100 works also well for me, Field Group 3.4 and Drupal 10.1.6 with Claro theme.

The last patch #100 didn't work for me because https://www.drupal.org/project/drupal/issues/2722319 CKEditor removed the "required" attribute from the textarea during startup

The last patch #100 didn't work for me because https://www.drupal.org/project/drupal/issues/2722319 CKEditor removed the "required" attribute from the textarea during startup. So I adjusted the patch with these changes.

Hi everyone,

Thanks a lot for raising this issue and contributing a patch, it's greatly appreciated !

I would like to confirm the patch from #116 applied properly with composer and seems to have fixed the issue in my case with the Gin admin theme and horizontal tabs (field_group), with the following versions:

• drupal/core: 10.2.0
• drupal/field_group: 3.4.0
• drupal/gin: 3.0.0-rc8

 
Client side validation now seems to be working properly by changing to the tab with the required field and focusing the right element.

Thanks again very much for your help with this issue.

Correction:
After doing a little bit more testing, I've been having the following JS error with the patch from #116 after saving a content form:

Uncaught TypeError: Cannot read properties of null (reading 'classList')
tabs.js line 119
at Drupal.FieldGroup.fieldIsValid (tabs.js?119:34)

Which seems to correspond to the following line of code:
https://git.drupalcode.org/project/field_group/-/merge_requests/40/diffs...

Added above at #113:
@brandonlira: Not sure exactly what use case that should cover but there might be a little bit more testing to be done, with perhaps a few more cases/checks to be added in the JS code.

Reverted to using patch from #100 which fixed my validation issue without prompting this JS error on form save.

Thanks again everyone for the great help!

the patch #116 worked for me.

I have a site where the node aded form for a content type has every element inside a collapsed fieldset: applying the patches in #100 and #116 still generated JS errors that silently prevented form submission when I trry to submit the form without filling anything.

#116 worked for me in Gin admin theme with horizontal tabs. But when i add a paragraph with field groups, it doesn't work anymore

The patch provided in #100, the one in #116 and MR!40 does not fully work for me.
I use horizontal tabs with a Claro 10.2.5.
If there are required fields in another tab that haven't been filled out, the JS takes me to one of those other tabs when I add a paragraph to the current tab.

Small update of patch provided in #100 in order not to break the behavior of adding a paragraph to a tab.

I tried '.form-submit:not([formnovalidate,.field-add-more-submit])' but it was not a valid selector (at least on firefox) ; so I just chained another :not() => '.form-submit:not([formnovalidate]):not(.field-add-more-submit)' and I am wondering if it's a good idea to have an array declaration in the first "not" since it's not well supported by all browsers yet.

#124 applied and fixes the issue!
Merci @MacSim !

any other testers?

To help getting this committed have I applied this into one of our production sites. I'll also make sure to send testers in there and take if for a spin.

Bit of a mess between patches & merge requests & outdated merge request fork.

Now the remaining MR is actually merge-able and contains identical content to the patch in #124. As such, marketing this as RTBC as I haven't actually made any change - just did a bunch of issue clean-up - and testing this it works as expected.

For future travellers please follow https://www.drupal.org/docs/develop/git/using-gitlab-to-contribute-to-dr... and download the patches locally from the MR to your project as per the recommendations/instructions rather than adding more patches here and having patches and MRs diverge again. Ie, let's keep us all moving forward on the same track and make life easier for the maintainers of this module to review & merge. Thank you!

Okay I believe credit list is also now up to date up; tried to also help maintainers by reviewing all people who have made contributions matching/exceeding the guidelines (ie, not just 'it works' type comments, meaningful reviews, code contributions, etc)

Okay I have made changes now, sorted all eslint errors, fixed typos.

The phpstan issues are unrelated to this MR, they are new to the module and therefore raised separately.

To help progress this issue if someone could please:

1. Review and test #3456987: Fix deprecated extending of render element to RTBC it so tests here can go all green (including phpstan)
2. Re-review this consider the changes I made to eslint/typos to get this back to RTBC

Then we'll hopefully all get the satisfaction of getting a 6 year old issue over the line :)

tested MR!57 on D10.3, php 8.3, on 3.x-dev@dev
looks good!

Thanks for fixing the patches/MRs!

I've just tested on D10.2.6, php 8.3, on 3.x-dev@dev and it doesn't get applied.
I attached 2 screenshots: first when applying the patch through composer.json and the second manually.

I found the same as andreic, the code updates do not apply on 3.x-dev@dev or 8.x-3.6 for us.

@Emircan Erkul there is no point of creating a new MR (unless the current one cannot be updated easily)

for me also patch from #99 broken after 3.6 upgrade

I've just used the latest version of the module (3.6.0 from 3rd of Aug) and now I get for some horizontal tabs a double star (**) for tabs that are required and one start (*) for those that are NOT required.

Also, the main problem still stands: when I fill in the fields in the first tab and click Save at the bottom, nothing happens. It should open the next horizontal tab and highlight the next field that is required to complete, right?

i also see the double stars that Andreic is seeing after applying mr57 against 3.6 so setting to needs work..

Patch for 3.6

The patch applied successfully and it also fixed the issue.
But what is going on with the double stars (the star for required fields) on vertical/horizontal tabs? I would add a screenshot but I don't have that option anymore for some reason.

Screenshot added.

Never mind, I found the patch for that in https://www.drupal.org/project/field_group/issues/3395375.
This issue can be closed now.

This issue can be closed now.

why should the issue be closed... it was not about the 2 Stars...
but about "HTML5 Validation Prevents Submission in Tabs" the thing to do would be to update the mr to match patch 148 and set the issue back to needs review or RTBC

Right, closed as in resolved further, meaning MR and RTBC.
Sorry, I wrote that in a hurry.

I looked to get the latest patch into the MR. Im seeing indentation changes (some funky indentation going on), but I can't see any functional differences compared to the MR, am I missing it? Is the patch meant to be introducing something different vs the MR?

I'd be happy to merge this, once someone resolves this finally!

@anybody, the MR is ready, PHPStan issue in unrelated deprecation, double asterisk in another issue, this is RTBC as far as I can tell

Taran, thanks for confirming! For ease of maintainers review reference for double asterisk issue is #3395375: Duplicated required marks in field tabs with GIn admin theme I believe.

Thank you all! Let's finall merge this into 4.x as RTBC has been confirmed several times and tests are green.
Please try 4.x in dev environments to ensure a brighter future :)

A test is failing now, someone please needs to take a look. Thanks!

Just talked with @Anybody internally, and we'll postpone this issue for now. We'll fix #2787179: Ensure visibility of invalid fields (JS) first, which solves a quite similar (maybe even identical) issue and then people can give feedback here if anything else has to be fixed here!

Issue #2787179: Ensure visibility of invalid fields (JS) is now fixed in 4.x. and there is follow up issue from that that might be useful to keep an eye on #3473361: Multiple required fields on multiple tabs do no trigger frontend validation. Not sure if we should postpone this issue on that. Changing to NW.

Postponed on #3473361: Multiple required fields on multiple tabs do no trigger frontend validation as of #167. Makes sense for now.

found the patch that works for 8.36 https://www.drupal.org/files/issues/2023-04-07/2787179-highlight-html5-v...
#33 on this page https://www.drupal.org/project/field_group/issues/2894351#comment-15712685

I fixed the setGroupWithfocus function call to setGroupWithFocus (camel case missing on focus)

Patch #33 from #2894351: Tabs with invalid input are not focused worked for me, using field_group 3.6.0. Thanks a lot @dianacastillo!

Quickly checking patch #87 vs. #33 in the other ticket, it looks like the work in this issue includes handling nested tabs as well as submit buttons using formnovalidate attribute; just an FYI for anybody needing to handle such use-cases.

#170 also applies correctly on top of 3.6.0; quick testing shows it working fine.

Facing the same issue with Drupal ~10.4

I'm not currently using this anywhere, but if we get a community-tested solution RTBC'd by enough people, I'm willing to merge a fix!

We have tested #170 and confirm it is working for us on D10.3.9 and D10.4.1. Thanks everyone!

In Field Group 4.x I can happily no longer reproduce the issue (perhaps because of #2787179: Ensure visibility of invalid fields (JS)). At the very least it needs an issue summary update I think.

Here is a gif of it working:

I have 4.x branch cloned and checked out directly.

Note that I can reproduce if I have a mix of horizontal and vertical tabs on the page, but I created a separate issue for that:

#3505096: Both Vertical and Horizontal tabs on the same page do not work

for version 3.6 this is the correct patch : "https://www.drupal.org/files/issues/2024-08-07/field-group-tabs-8.x-3.x...."

composer require 'drupal/field_group:3.6'

The patch provided in #179 works perfectly, except of the logic will be adapted to all input fields with a form-submit class. In my case with gin, this e.g. leads to adaption of the logic if i want to insert a media via media-library and click on "Insert selected" this button also has the class form-submit and therefore causes misbehavior. Here the modified patch for this special case

I found the same as @scott_euser in #177: Upgrading to field_group 4.x resolves the issue as seen in the gif.

Tabs are still not marked as required, but that's a separate issue I'm sure.

Thanks @maskedjellybean so we can keep this closed. Could someone have a look if we already have an issue for the required marking? (I think I saw one, but very busy currently - so maybe it could be linked here)

@anybody there's some work going on in 3160987

Hello, for patch provided in #180 and in case of bootstrap_barrio theme i had to change the below line:
$(context).find('.node-form input.form-submit').click(function () {
to this one:
$(context).find('.node-form .form-actions .form-submit').click(function () {