[HOLD for payment 2023-04-20] [$4000] Using a header (#) and a space or bold (*), then adding a code block results in the code block being bolded for a moment

[kavimuru]

If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!

---

Action Performed:

1. Open a chat
2. Start a message with # then a space
3. Add a code block using three backticks

You should see the code block go bold, then normal.

Expected Result:

A code block should not show bold text.

Actual Result:

Bold text appears temporarily, then reverts to normal text.

Workaround:

unknown

Platforms:

Which of our officially supported platforms is this issue occurring on?

• Android / native
• Android / Chrome
• iOS / native
• iOS / Safari
• MacOS / Chrome / Safari
• MacOS / Desktop

Version Number: 1.2.72-0
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos:

Screen.Recording.2023-01-06.at.3.11.31.PM.mov

Recording.1530.mp4

Expensify/Expensify Issue URL:
Issue reported by: @gadhiyamanan
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1672998135151449

View all open jobs on GitHub

Upwork Automation - Do Not Edit

• Upwork Job URL: https://www.upwork.com/jobs/~014c5422ceeae647ae
• Upwork Job ID: 1626059997054926848
• Last Price Increase: 2023-03-13

[MelvinBot]

Triggered auto assignment to @jliexpensify (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[MelvinBot]

Bug0 Triage Checklist (Main S/O)

• This "bug" occurs on a supported platform (ensure Platforms in OP are ✅)
• This bug is not a duplicate report (check E/App issues and #expensify-bugs)
  • If it is, comment with a link to the original report, close the issue and add any novel details to the original issue instead
• This bug is reproducible using the reproduction steps in the OP. S/O
  • If the reproduction steps are clear and you're unable to reproduce the bug, check with the reporter and QA first, then close the issue.
  • If the reproduction steps aren't clear and you determine the correct steps, please update the OP.
• This issue is filled out as thoroughly and clearly as possible
  • Pay special attention to the title, results, platforms where the bug occurs, and if the bug happens on staging/production.
• I have reviewed and subscribed to the linked Slack conversation to ensure Slack/Github stay in sync

[jliexpensify]

Can reproduce in v1.2.72-0 as well. Seems to be occurring for Android (v1.2.71-1) as well.

[MelvinBot]

Job added to Upwork: https://www.upwork.com/jobs/~014c5422ceeae647ae

[MelvinBot]

Current assignee @jliexpensify is eligible for the External assigner, not assigning anyone new.

[MelvinBot]

Triggered auto assignment to Contributor-plus team member for initial proposal review - @aimane-chnaif (External)

[MelvinBot]

Triggered auto assignment to @roryabraham (External), see https://stackoverflow.com/c/expensify/questions/7972 for more details.

[eh2077]

Just tested using GitHub comment. It should be displayed in bold right?

[jliexpensify]

@eh2077 - code blocks shouldn't be bold at all.

[dgaisan]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Bold text appears temporarily, then reverts to normal text when sending # ```to send``` message

What is the root cause of the problem?

When the message is synched with the backend it's being changed from the original one:

• original message: # bold code
• The message gets HTML-escaped before synching with the backend: <h1><pre>bold code<pre></h1>
• Then message is send to the backend, and after being processed on the backend it looks as following: <h1></h1><pre>bold code</pre>

Therefore the text flickering (from bold to regular) happens due to this change on the backend.
This can be clearly seen in offline mode: the message stays bold forever, until the app goes back online

What changes do you think we should make in order to solve the problem?

To make sure everything is consistent I suggest to simply get rid of Bold property in the message before it's even rendered for the first time.
The change can be made in this method
The advantage of this solution is the fact that it's going to be very clean, we won't need to make changes on the backend, and we'll maintain consistency w/o introducing any regressions...

What alternative solutions did you explore? (Optional)

None

[allroundexperts]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Message turns bold temporarily when enclosed with a # followed by ``` or `.

What is the root cause of that problem?

The frontend parses the expression in a different way then the backend. Frontend encloses the <pre> tag inside the h1 tag while the backend does not enclose the pre tag inside h1.

What changes do you think we should make in order to solve the problem?

We can change the ExpensiMark # parsing rule such that it ignores adding h1 if pre or code tag is present.
The rule exists here:
https://github.com/Expensify/expensify-common/blob/4f61e5529c89936bfb72b6cee53250990c16f188/lib/ExpensiMark.js#L166

The new regex would look like the following:

/^#(?!#) +(?!<(pre|code)>)(.+)$\s*/gm

The replacement part of this regex needs to be changed as well:

replacement: '<h1>$2</h1>',

This works well after the fix.

Screen.Recording.2023-02-16.at.2.07.00.PM.mov

What alternative solutions did you explore? (Optional)

Reminder: Please use plain English, be brief and avoid jargon. Feel free to use images, charts or pseudo-code if necessary. Do not post large multi-line diffs or write walls of text. Do not create PRs unless you have been hired for this job.

Ignoring the # if any tag is present after it. I think we don't want to do that. We should ignore only if code or pre tag is present.

[moezh]

Proposal

Please re-state the problem that we are trying to solve in this issue.

Bold text appears temporarily, then reverts to normal text, when sending # ```code``` .

What is the root cause of that problem?

The problem is related to the way the frontend and backend parse expressions, resulting in differences between the two. Specifically, the frontend sends <h1><pre>code<pre></h1>, while the backend replies with <h1></h1><pre>code</pre>.

What changes do you think we should make in order to solve the problem?

To address the root cause of the problem, I recommend making the following changes:

• Adjust the CSS for the "pre" class to prevent it from inheriting font weight and size from its parent.
• Change the CSS for the "h1" class to use lineHeight instead of marginBottom, to take into consideration that the title might be empty.

I believe that the changes outlined above are the most effective and simple way to address the problem.

Screen.Recording.2023-02-16.at.12.41.19.PM.mov

What alternative solutions did you explore? (Optional)

None

[Santhosh-Sellavel]

@aimane-chnaif @roryabraham

Not sure whether this is a valid bug here is what Github does

Screen.Recording.2023-02-17.at.1.37.11.AM.mov

[allroundexperts]

@Santhosh-Sellavel Here's how it works on Slack. IMO, it makes more sense to not allow this behaviour.

[Santhosh-Sellavel]

@allroundexperts Slack doesn't support # styling text as a header as we do. So the behavior aligns with what GitHub does i.e support # for header and code or code blocks

[allroundexperts]

@allroundexperts Slack doesn't support # styling text as a header as we do. So the behavior aligns with what GitHub does i.e support # for header and code or code blocks

You're right. My bad.

[moezh]

Regardless of whether the code block must appears in bold or normal text, it should not inherit any styling from its parent element. The code block should maintain its own distinct styling and formatting. The code inside <h1></h1><pre>code</pre> or <h1><pre>code</pre></h1> should look identical in terms of formatting and styling.

[moezh]

After reviewing how GitHub works, the code block does inherit its styling from its parent element. So, please disregard my last message.

[MelvinBot]

Triggered auto assignment to @maddylewis (Bug), see https://stackoverflow.com/c/expensify/questions/14418 for more details.

[jliexpensify]

Hi @maddylewis - I'm OOO so assigning to you for the payment + list (here's the amounts)

Upworks job is here: https://www.upwork.com/jobs/~014c5422ceeae647ae

[maddylewis]

thank you so much for the clear instructions @jliexpensify!

i will process these payments by EOD 👍

[maddylewis]

paid!

[aimane-chnaif]

Oh, payment is too early. PR didn't hit the production yet and should also wait for 7 days regression period.

[maddylewis]

well, dammit.

[MelvinBot]

Reviewing label has been removed, please complete the "BugZero Checklist".

[MelvinBot]

The solution for this issue has been 🚀 deployed to production 🚀 in version 1.2.99-6 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue:

• handle code block inside heading1, bold, italic markdown #16437

If no regressions arise, payment will be issued on 2023-04-20. 🎊

After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.

• External issue reporter
• Contributor that fixed the issue
• Contributor+ that helped on the issue and/or PR

As a reminder, here are the bonuses/penalties that should be applied for any External issue:

• Merged PR within 3 business days of assignment - 50% bonus
• Merged PR more than 9 business days after assignment - 50% penalty

[MelvinBot]

BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:

• [@aimane-chnaif / @roryabraham] The PR that introduced the bug has been identified. Link to the PR:
• [@aimane-chnaif / @roryabraham] The offending PR has been commented on, pointing out the bug it caused and why, so the author and reviewers can learn from the mistake. Link to comment:
• [@aimane-chnaif / @roryabraham] A discussion in #expensify-bugs has been started about whether any other steps should be taken (e.g. updating the PR review checklist) in order to catch this type of bug sooner. Link to discussion:
• [@maddylewis] Determine if we should create a regression test for this bug.
• [@aimane-chnaif] If we decide to create a regression test for the bug, please propose the regression test steps to ensure the same bug will not reach production again.
• [@maddylewis] Link the GH issue for creating/updating the regression test once above steps have been agreed upon:

[gadhiyamanan]

@maddylewis please close the upwork contract
Thanks!

[aimane-chnaif]

There's no PR caused regression so we can check off first 3 items.
We already have automated tests with good example cases in expensify-common repo so I think no need regression test step.
@roryabraham do you agree?

[aimane-chnaif]

The regression period is over. No regressions found.
I'd like to discuss timeline bonus/penalty.

Here's summary:

• Contributor assigned on Mar 23
• Issue put on hold while working on backend fix
• Later, we discussed the expected behavior in slack
• And posted expected result finally landed on Mar 31 - I think this can be actual assign date
• External PR approved by C+ on Mar 31
• Waiting period to get approval from @roryabraham
• @roryabraham came back and reviewed PR on Apr 10
• External PR merged on Apr 11
• App PR finally merged on Apr 11

Total days elapsed: 13 business days (Mar 23 - Apr 11)
Hold period: 6 business days (Mar 23 - Mar 31)
Waiting for engineer period: 6 business days (Mar 31 - Apr 10)
So I can say PR was merged within 2 business days without external factors

[maddylewis]

okay, so it sounds like @aimane-chnaif and @situchan are both eligible for the 50% merge bonus. is that correct?

would the bonus be 50% of the final payment or the original payment (ie, $500 or $2000)?

[aimane-chnaif]

final payment

[maddylewis]

offers sent

[gadhiyamanan]

@maddylewis just a reminder to close the Upwork contract

[maddylewis]

payments sent - i believe we are all set here.