H2 heading block text changed to bold

[reginabally]

Describe the bug
It was reported in 4340849-zd-woothemes that the H2 heading block text was changed to bold when editing the content on WPiOS 18.2.1. This was reported on an Atomic site using the Seedlet theme. I was able to reproduce this on a Simple site with the same theme but the outcome isn't consistent.

To Reproduce
Steps to reproduce the behavior:

1. Activate the "Seedlet" theme on a WordPress.com site.
2. Make sure font selection for the theme is set to "Theme Default" on https://wordpress.com.
3. Create a new post at My Site > Blog Posts in the app.
4. Tap + to add the Heading block.
5. Type "What I'm liking" in the header block.
6. Preview the post and noticed the "I'm" text becomes bold.

Expected behavior
I would expect the heading text format is consistent.

Screen recording

heading-test.mp4

Smartphone (please complete the following information):

• Device: iPhone 11
• OS: iOS 14.8
• Version 18.2.1

[hypest]

👋 @antonis , could this perhaps be relevant to GSS work?

[antonis]

Thank you for reporting this @reginabally and thank you for the ping @hypest 🙇
I confirm that I was able to reproduce this on iOS only (on Android it works fine) 😵‍💫
When I right I'm manually it seems to work as expected. When I do it using the suggestions it turns to strong 💪

im.mov

I'm tempted to say that this is some iOS Apple gem that is hard to override but maybe it is worth digging deeper. Wdyt?

ps. I don't think this has anything to do with the GSS work but @geriux may confirm this.

[twstokes]

I wonder if it's related to the issue this PR dealt with.

Adding the tagsToEliminate={ [ 'strong' ] } prop here cleared it up for me in my quick tests.

[hypest]

Thanks for checking this out @antonis , and nice find @twstokes ! Tanner, want to go ahead and prepare PRs with that solution so we can test it out? Thanks!

[twstokes]

Sure @hypest - will do.

[twstokes]

After digging into this deeper I've determined that the solution I proposed above doesn't quite get us there. It will block bold styles on headings when it happens unintentionally as in this case, but also when the user intentionally tries to make heading text bold. We wouldn't want to strip that ability away. It worked for the original PR because title styling isn't possible.

It may require digging into Aztec to uncover the root. It seems <strong> tags are placed around any heading text inserted by the OS - either via autocorrect or the spacebar double-tap.

I'd be happy to do a deep dive on this since it involves iOS, but wanted to run this idea by you first, @hypest. Thanks!

[hypest]

Hmm, right, striping the strong can't be the solution for every case, thanks for verifying @twstokes.

Regarding working on it, I'm concerned by the fact that the output html is affected so, I consider that both a writing flow issue and a content issue. I'll take you on your offer to dig deeper to fix it on the Aztec (perhaps) side @twstokes , thanks. But, let's start with a tight timebox for it, say, one day max. We can re-assess afterwards. WDYT?

[twstokes]

Hmm, right, striping the strong can't be the solution for every case, thanks for verifying @twstokes.

Regarding working on it, I'm concerned by the fact that the output html is affected so, I consider that both a writing flow issue and a content issue. I'll take you on your offer to dig deeper to fix it on the Aztec (perhaps) side @twstokes , thanks. But, let's start with a tight timebox for it, say, one day max. We can re-assess afterwards. WDYT?

Sounds good @hypest, I'll report back.

[twstokes]

I have a WIP PR here that appears to solve the problem, but I don't have the highest confidence that it's the best solution.

In my troubleshooting I found that when invoking autocorrect (or any other OS level string update like double-tapping the spacebar), the string inserted into Aztec was missing heading attributes that we rely on to determine whether text is a heading or bold (or both). If the attribute is missing in the new string it'll ultimately get processed with <strong> tags around it.

The potential fix is to insert this attribute when we detect it's missing.

[SiobhyB]

Just noting that another way this bug emerges is when splitting a heading block that has some words that have been autocorrected. The difference in bolded words become visible as soon as a block is split.

Originally reported at WordPress/gutenberg#36784 (but closed due to being a dupe).