Gutenberg-mobile: Formatting bugs triage

[koke]

I'm migrating the list from #275 here so we can test again and create individual issues for those bugs that are still relevant:

• [x] [Android] Word gets "bold": Start with two words text like "two words". Place the cursor between the space and the "w". Tap on "B" to turn on bold. Type a few chars and press "space". Notice the "word" becoming strong while it shouldn't. 👉 #824
• [x] [iOS] Style doesn't apply: Start with "two words". Place the cursor between the space and the "w". Tap on "B" to turn on bold. Type a few chars and notice that only the first new char is in bold. The rest are not styled.
• [x] [Android] Selection is dropped. Select a word and style it (example: to bold) by tapping on a toolbar button. Word gets stlyed but selection is removed. 👉 #825
• [x] Haven't replicated this but as per Tug: it seems AztecEditor-iOS returns <strike> tags instead of <del> in some cases. It causes inconsistencies in the selected formats on iOS. 👉 #832
• [x] ~[Android] Known issue: "b" tags are not recognized by the format-library as "bold" so, the toolbar doesn't highlight the "B" button when the cursor is on a <b></b> section. That behavior is same on GB-web but I think it's counter-intuitive.~
• [x] [iOS] on iOS, the editor mutates the markup, replacing <b> with <strong>s. Issue it that this doesn't align with what Gutenberg-web does. 👉 #832
• [x] [Both platforms] Styling issues as reported by Thomas above. 👉 #623
• [x] [Android] Style button gets highlighted again. See video reported by @daniloercoli : https://cloudup.com/cXNXc52YxKK 👉 #834
• [ ] [Android] Note for the next pass/fixes: _setting_ the last content from the "onSelectionChange" event feels wrong and we should remove it. Makes the logic more complex and it may introduce Aztec/RN sync bugs.

[koke]

[iOS] Style doesn't apply

Seems to work fine on WPiOS 12.1

[koke]

AztecEditor-iOS returns <strike> tags instead of <del>

"b" tags are not recognized by the format-library as "bold"

the editor mutates the markup, replacing <b> with <strong>s

Just by those descriptions, I'm not sure how much we should care about this. Is this something that would happen often? Can we describe it as an actual use case that a user would experience? @Tug @hypest

[koke]

Style button gets highlighted again

I can't reproduce this one on alpha-160 🎉

[koke]

setting the last content from the "onSelectionChange" event feels wrong and we should remove it

@hypest Feel free to create an issue for this if it's still relevant, but I'm keeping it out of the bug fixes list

[Tug]

AztecEditor-iOS returns <strike> tags instead of <del>

I can reproduce quite consistently when mixing formats (bold inside strike inside strikethrough, at some point aztec iOS rewrites the HTML using it's own tags and it causes inconsistencies in the current formats.

"b" tags are not recognized by the format-library as "bold"

Well it's also the case on the web. Unless gutenberg web decides to tackle it we should probably ignore this "bug"

the editor mutates the markup, replacing <b> with <strong>s

Same as the first bug you mentioned (with del and strike), I think it's quite important that we fix it imo. We either need to switch the default tags for Aztec (easiest solution) or distinguish between different types of the same styles and have a 1:1 mapping between our aztec format and our generated tags (harder).

[hypest]

@koke koke closed this 2 hours ago

Seems like at the time of writing, there are a few checklist items that are still undone so, can you share more context about why the ticket was closed @koke ? Thanks!

[koke]

I can reproduce quite consistently when mixing formats

@tug I'm trying every combination I could think of in WPiOS Internal 12.1, and can't see any issues. Can you share some reproduction steps?

[koke]

can you share more context about why the ticket was closed

@hypest sure. As I mentioned, the remaining issues didn't seem worth fixing from my understanding at the moment. After Tug's comment, if we can reproduce the tag rewrite thing, it should be on a new separate issue.

More generally, I think master issues/checklists like this have been useful in the past but can be problematic when trying to prioritize each item separately, or track their progress. I think we should start restricting master issues to be temporary. Like this one, make a checklist for a bug scrub with the intention to be done with it in a short period of time. Any results that take longer would go to a new issue.

[koke]

Created #832 for the nested tags problem

[mzorz]

[Android] Style button gets highlighted again. See video reported by @daniloercoli : https://cloudup.com/cXNXc52YxKK

I can't reproduce this one on alpha-160 🎉

I can reproduce on develop on a Pixel 2 with Android 8.1 😕

Will open an issue and track it down here 👍

[hypest]

Thanks for expanding @koke .

How about striking through the checklist items we think don't need action or are already obsolete? What is weird to me is to have a checklist with unchecked items but the whole ticket being closed. The items should either be "open" (and the ticket open too) or closed in some form (either checked or striken-through). Otherwise it's not clear if tasks are actually pending or not.

[koke]

I can reproduce on develop on a Pixel 2 with Android 8.1 😕

Will open an issue and track it down here 👍

😢 Thanks for checking @mzorz. I've added a note to the "2.0 Bugs" column in the right position, please convert that to an issue and add the details there

[koke]

@hypest I just wanted the issue out of the project 😂 I've reopened and removed it from the project until we have issues for all the items

[mzorz]

I've added a note to the "2.0 Bugs" column in the right position, please convert that to an issue and add the details there

Converted to issue and added details in #834

[SergioEstevao]

It looks all the issues are addressed and the only remaining issue is a tech debt question for RichtText.