ACF blocks using acf_inline_toolbar_editing_attrs() and acf_inline_text_editing_attrs() spill internal attributes over into frontend markup #1021

Describe the bug
When using acf_inline_toolbar_editing_attrs() and acf_inline_text_editing_attrs(), it works as expected in the block editor: all of the html attributes ACF uses are there:

<div data-acf-inline-fields-uid="block_...description2" data-acf-inline-fields="[{...}]" role="button" tabindex="0" class=" text-black/80 prose text-lg" style="pointer-events: all;">...</div>

However, there is no guard against exposing this on the frontend too, making the somewhat sensitive internal ACF info, field names etc. visible to potential malicious actors.

It also messed up screen reader support, as it inserts role="button" and tabindex="0" to divs and other elements that should not be labeled as such.

I believe this to be a regression as this didn't use to happen.

To Reproduce

1. Create an ACF Block using the Blocks V3 API and add a wysiwyg field or another unrenderable field in the new inline editing experience
2. Use acf_inline_toolbar_editing_attrs() or acf_inline_text_editing_attrs() to surface an unsupported attribute which would normally require opening the sidebar or expanded editor, like so:

<div <?= acf_inline_toolbar_editing_attrs( [ 'description1' ] ); ?> class=" text-black/80 prose text-lg">
    <?= wp_kses_post( get_field( 'description1' ) ?? '' ); ?>
</div>

3. Examine the markup generated in the block editor and frontend portions
4. See the issue

Expected behavior
There should be a guard to only show these in the block editor. I wrote my own:

function helper_acf_inline_toolbar_attrs( array $fields, array $args = array() ): string
{
	if ( ! acf_is_block_editor() )
		return '';
	return acf_inline_toolbar_editing_attrs( $fields, $args );
}

However, i found that the acf_is_block_editor() function isn't 100% reliable and sometimes fails, fully removing the inline toolbar attributes, but that's probably a separate bug report. But it means that i cannot use it as it breaks, and haven't found a suitable workaround. If someone more knowledgeable in ACF could recommend me what guard method to use instead that works 100% that would solve my issue, however i believe this should be fixed in ACF itself.

Version Information:

• WordPress Version: 7.0.2
• PHP Version: 8.4
• ACF Version: ACF Pro 6.8.5
• Browser: Firefox(Zen Browser) 152.0.6