Horizontal tab title is not properly retrieved from the details form element and all title html attributes are lost

We had same issue in our project. But your patch was leading to wrong results. In chrome, the patch worked, in firefox, all tabs got a link as title. That's because chrome already has details support.
In attachment my patch that i'm committing. Instead of taking the full html, the text of the first element found inside the summary, after removing all it's children.

I can confirm even with the latest release I still needed to switch to the following like the 2nd half of the patch in #2. Otherwise the tabs still say Show in them.
.append(tab.title = '<strong>' + settings.title + '</strong>')

same, need patch in #2 in order for horizontal tabs to display tab title in firefox

I'm with hchonov here - the commit really didn't address the actual problem. It actually made the situation worse in some circumstances. e.g. I lose tab titles entirely on browsers requiring Modernizr! (collapse.js is added much later to the page, so the .details-title element the commit depended on is not even added to the page, and so the summary is set to an empty string.)

So, while this doesn't fix the original issue at all, here's a patch that undoes zuuperman's commit 2730393, which can be a start point for others to build upon.

Oh interesting, I hadn't seen #2743127: Add core/drupal.collapse dependency, which has since 'fixed' the dependency on core/drupal.collapse. Two things there though:

1) Core's vertical tabs intentionally loads collapse after its vertical tabs javascript, so why should horizontal tabs be any different?
2) As stated in my previous comment, the commit for this issue didn't actually address the original problem, but a slightly different one, so I still think it should be reverted and a different solution found that does actually retain the HTML.

So, having dug yet further into the problem around depending on core/drupal.collapse, the negative weight of the formatters/tabs/horizontal-tabs.js file in the field_group/element.horizontal_tabs library actually means that it comes before core/drupal.collapse in source order, despite depending on the latter. Depending on a library simply ensures the dependency is added to the page, not that it will come out first.

(Core issue #1945262: Introduce "before" and "after" for conditional ordering in library definitions is about resolving this sort of thing: weights simply aren't the way to go for this sort of thing.)

Given that, I think this is now an even stronger argument for removing the need for Modernizr or the collapse library, to avoid all these issues, given that it wasn't actually solving the problem here in the first place. Then once we're back in a working state, the actual feature request of this ticket (allowing HTML in tab titles) can be worked on.

Thanks for commit in #14. Sadly the patch had a mistake:

.append(tab.title = $('<strong></strong>').text(settings.title))
should have been
.append(tab.title = $('<strong></strong>').html(settings.title))

to preserve HTML in the title. For example to allow items or other formatting. This should not be removed in the JS code.

I tested that change and now everything works great. I'll create a new patch against 8.x-3.x-dev (because I think 1.x will be dropped sooner or later?)

Patch attached. Please review. My tests were good.

+1 for RTBC

Equally as problematic is the line above the latest patch in #16

var summary = summaryElement.clone().children().remove().end().html();

By removing the children, if you've done some work to get HTML elements into the tab title, e.g. like an SVG icon then they'll be removed by this.

#16 works fine. If @benjy likes to create a patch which also fixes #18 that would be great. Otherwise let's first of all fix one problem after the other instead of waiting for further month ...

#15 has already been fixed without a reference to this issue. So this is FIXED now. If a new problem appears please create a new issue.
@zuuperman, it would have been perfect to mention this issue and the related persons when fixing #15, but it's most important that it's fixed :)

Sorry I was wrong... we were just using that patch ... this is still an open issue and #16 should be applied.

Allowing html in labels is a very bad idea. This is the result if I apply your patch:

Marking this as no fix. If you really need html in your titles, you can write custom javascript.

@zuuperman Sure, that value would be bad - so filter_xss_admin(), or similar, should be applied to the setting's value on the server side. I don't see the need to still reject other people's genuine use case for HTML in labels - just to handle the HTML sensitively.

But if you're the maintainer of the module, and will not allow this change, then I guess those of us that need this will have to solve the problem elsewhere. Whether that means using other modules instead, or ones that override what field_group does, I guess.

The text is already escaped. But by first using .text, and after that .html, all html codes are back.

So if you want to keep it safe, you need to go to adding Xss::filter when preparing the title. Problem there is you need to add a list of allowed html codes, so very specific to peoples current requirement (example only i tags and svg tags). The moment people start using other html tags, it breaks again.

@zuuperman, that's what Xss::filterAdmin() is for? Tags that would be permissible for admins. Otherwise use Drupal's input format system which is for configuring what is allowed markup.

Would you accept a patch that adds Xss::filterAdmin() on the server-side, so that .html() can then be used on the client-side?

@james.williams I can agree to allow filterAdmin. If people want svg, they'll need to add it via custom code.

Perfect, I agree filterAdmin would be the right approach! :)

Would #3024409: Add option to allow HTML in labels help ?

I also committed #2846617: Do not translate field group labels using interface translation. - it changes the default way to translate labels and description in general (better for config import/export as well).

Yes, I should think so! Let's just close this ticket as a duplicate, because that's looking at solving the issue that caused this problem, i.e. support for HTML in group labels. There was discussion about Modernizr's place in all this, but that's a side-issue really.