Uh oh!
There was an error while loading. Please reload this page.
Fix legacy task list position calculation - #3491
Conversation
🦋 Changeset detectedLatest commit: f5e867b The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
size-limit report 📦
|
JelloBagel
left a comment
There was a problem hiding this comment.
Thanks for fixing this bug! ✨
Looks good to me. Should we add a test for this?
| type TaskListItem = ListItem & {taskBox: '[ ]' | '[x]'} | ||
| const isCodeBlockDelimiter = (line: string) => line.trimStart().startsWith('```') |
There was a problem hiding this comment.
The spec is a little looser than this, so there will be some types of code blocks that don't get caught.
They can be delimited by tildes instead of backticks:
~~~example~~~They can also have more than three backticks:
````example````In this case, you'd need to keep track of how long the starting delimiter is so that you can ensure the ending delimiter is the same length.
There was a problem hiding this comment.
Great point! Will make that update.
@JelloBagel Tests added. :) |
d2a6ce0 to
a99fb3eComparea99fb3e to
8e5df65Comparejoshblack
commented
Jul 7, 2023
FYI @siddharthkp for release next week this would be great to get in! |
| // Make check for code fences more robust per spec: https://github.github.com/gfm/#fenced-code-blocks | ||
| const parseCodeFenceBegin = (line: string) => { | ||
| const match = line.match(/^ {0,3}(`{3,}|~{3,})[^`]*$/) |
There was a problem hiding this comment.
| constmatch=line.match(/^{0,3}(`{3,}|~{3,})[^`]*$/) | |
| constmatch=line.match(/^*(`{3,}|~{3,})[^`]*$/) |
Looks like the spec says that an opening fence can be indented an indefinite number of spaces, but the closing fence can only be indented up to 3.
There was a problem hiding this comment.
The spec states that both an opening and closing fence can be indented no more than three spaces:
A fenced code block begins with a code fence, indented no more than three spaces.
The closing code fence may be indented up to three spaces
I also tested and confirmed this is the case.
There was a problem hiding this comment.
Huh, the spec has an example with more than three, but I think I misread it - it looks like that doesn't actually make a code block. So, all good 👍
There was a problem hiding this comment.
Side note, maybe we also should filter out lines starting with more than 3 spaces?
Ie, this is not a checklist item, but it's also not in a code block:
- [ ] example
This came from this markdown:
- [ ] exampleProbably something to think about for a different PR though
| } | ||
| const isCodeFenceEnd = (line: string, fence: string) => { | ||
| const match = line.match(new RegExp(`^ {0,3}${fence}${fence[0]}* *$`)) |
There was a problem hiding this comment.
| constmatch=line.match(newRegExp(`^ {0,3}${fence}${fence[0]}* *$`)) | |
| constmatch=line.match(newRegExp(`^ {0,3}${fence} *$`)) |
I think the closing fence needs to have exactly the same number of delimiters as the opening fence. For example, this is valid:
```one````we are still in block `one` here```There was a problem hiding this comment.
Technically the closing fence needs to have "at least as many" delimiters as the opening fence:
The content of the code block consists of all subsequent lines, until a closing code fence of the same type as the code block began with (backticks or tildes), and with at least as many backticks or tildes as the opening code fence.
So in the case you mentioned above, the second line would suffice as a closing fence since it has "at least" three backticks (tested in the issue editor on prod and confirmed).
There was a problem hiding this comment.
Oh wow, you are totally right 👍 I definitely misread that
Uh oh!
There was an error while loading. Please reload this page.
nicolleromero
commented
Jul 10, 2023
Thanks, @joshblack! I added a changeset, but validation appears to be failing. Anything I should update? |
This PR fixes a bug where the combination of a tasklist + legacy task list in the side panel would cause a miscalculation of the checkbox position and result in the wrong checkbox being updated. Preventing checkboxes within code blocks from being included in the position calculation prevents this bug and other potential bugs (e.g., where a user includes the
- [ ]checkbox notation within a code block).Note: this fix was tested and works in both the previous and new issue viewer in Memex.
Screenshots
Before
Checkbox.bug.before.fix.mov
After
Checkbox.bug.after.fix.mov
Merge checklist
Take a look at the What we look for in reviews section of the contributing guidelines for more information on how we review PRs.