Internal links with checkboxes in headings: not clickable when ticked, and break when state changes

[nonobio]

Operating system

Windows

Joplin version

3.6.7

Desktop version info

Joplin 3.6.7 (prod, win32)

Appareil : win32, Intel(R) Core(TM) i5-4310U CPU @ 2.00GHz
ID client : 773c93d7dee04e1289cb896f235df6a3
Version de Synchro : 3
Version du profil : 49
Trousseau supporté : Oui
ID d'instance alternatif : -
Sync target: WebDAV
Éditeur : Markdown

Révision : af0cab6

Backup: 1.5.1
Bidirectional Links: 0.2.1
Combine notes: 1.2.3
Favorites: 1.3.2
Freehand Drawing: 4.3.0
Menu items, Shortcuts, Toolbar icons: 1.1.0
MultiMarkdown Table Tools: 1.2.1
Note list and sidebar toggle buttons: 1.0.3
Note overview: 1.7.1
Note Tabs: 1.4.0
Outline: 1.5.15
Persistent Editor Layout: 2.2.0
Quick Links: 1.3.2
Rich Markdown: 0.17.1
Rich Tables: 1.7.11
Search & Replace: 2.2.0

Current behaviour

Hi,

I use Outline to create links by right-clicking on headers:

Problem 1 — Link is not clickable when it contains a ticked checkbox: [x]

When a heading contains a ticked checkbox, the Outline plugin generates a link like this:

[My note#[x] title](:/131d7ddac2e94ec7a86e90631f47fbae#x-title)

In the editor, instead of the whole label being rendered as a clickable link, only the [x] part appears highlighted in blue, and the link cannot be followed with Ctrl+Click:

An issue about links and checkboxes was originally discussed in the Rich Markdown plugin (CalebJohn/joplin-rich-markdown#63), but for these actual problems, I tested with Rich Markdown disabled (and all my other plugins disabled too), and the same rendering issue occurs, so this may be a Joplin core bug.

If the checkbox is unticked ([ ]), the link is fully blue and clickable — but it still breaks if the state changes later (see Problem 2).

Problem 2 — The link breaks when the checkbox state changes after link creation

Joplin generates anchor links by slugifying the heading text. [ ] and [x] are treated differently during this process:

• ## [ ] title → #title
• ## [x] title → #x-title

So when I tick a checkbox (or untick it), any previously copied link becomes silently invalid.

Expected behaviour

Links containing a ticked checkbox should work.
Additionally, ticking or unticking a checkbox in a heading should not invalidate previously created links.

My idea for a solution

A fix for broken links containing a ticked checkbox would be good, but if checkboxes (ticked or unticked) in headings were ignored when generating anchors, the link would always work regardless of checkbox state, resolving both problems.

Workaround I'm currently considering

Only use unticked checkboxes in headings, and delete them when a task is finished (instead of ticking the box). I think it would work, but it's not as natural as ticking the checkbox.

Do you have any ideas for other workarounds or a fix?

Happy to provide any additional test cases or clarifications.
Thanks :)

[Sandesh13fr]

I investigated this a bit further and it looks like there are two related core issues here:

1. Heading anchors are generated from raw heading text, so a heading starting with [ ] and the same heading starting with [x] produce different hashes. That explains why copied links break after toggling the heading checkbox.

2. In the Markdown editor, checkbox/task-marker handling appears to be leaking into inline link text, which likely causes the [x] fragment inside the link label to interfere with normal link detection / Ctrl+Click follow behavior.

A focused fix would be:

• normalize heading text before slug generation by stripping only a leading task marker ([ ], [x], [X]) for anchor generation / matching
• restrict checkbox click/toggle handling to real task-list context so [x] inside link labels is not treated like a task marker
• add regression tests for both stable heading hashes and link-follow behavior with headings containing task markers

That should keep the change small and directly scoped to the reported issue.

P.S. : Currently working on the fix.

[Sandesh13fr]

I investigated this a bit further and it looks like there are two related core issues here:

1. Heading anchors are generated from raw heading text, so a heading starting with [ ] and the same heading starting with [x] produce different hashes. That explains why copied links break after toggling the heading checkbox.
2. In the Markdown editor, checkbox/task-marker handling appears to be leaking into inline link text, which likely causes the [x] fragment inside the link label to interfere with normal link detection / Ctrl+Click follow behavior.

A focused fix would be:

• normalize heading text before slug generation by stripping only a leading task marker ([ ], [x], [X]) for anchor generation / matching
• restrict checkbox click/toggle handling to real task-list context so [x] inside link labels is not treated like a task marker
• add regression tests for both stable heading hashes and link-follow behavior with headings containing task markers

That should keep the change small and directly scoped to the reported issue.

P.S. : Currently working on the fix.

Implemented the fix and kept it scoped to heading hash normalization plus task-marker/link interaction handling. Added targeted regression tests for both stable heading hashes and Markdown editor link-follow behavior.

[nonobio]

Thank you very much, I can't wait to try :)
I use the Rich Markdown plugin, among other things, to tick/untick the checkboxes by CTRL + click (including the checkboxes found in headers). I hope it will still work with this fix.

[Sandesh13fr]

Thank you very much, I can't wait to try :) I use the Rich Markdown plugin, among other things, to tick/untick the checkboxes by CTRL + click (including the checkboxes found in headers). I hope it will still work with this fix.

Happy to help.
Hope it resolves the issue you have been facing completely & works great..

[Sandesh13fr]

@nonobio If possible, could you please validate the scenarios from the PR description for #15040 on your side as well?

A confirmation from your side would be really helpful to make sure the fix matches the originally reported behavior before final review.
Thanks again!

[laurent22]

Hello, there should be just one bug per issue to make it easier to manage

[Sandesh13fr]

Hello, there should be just one bug per issue to make it easier to manage

Question.
Can I raise new separate issues for this bugs & then a PR for the same.
Also what are your thoughts on the bugs.🙂

[nonobio]

Hi,

@laurent22 I separated the issue into two new issues:

#15056

#15057

@Sandesh13fr tell me if you need I validate something with these new issues/PR.

Thanks :)

[Sandesh13fr]

Hi,

@laurent22 I separated the issue into two new issues:

#15056

#15057

@Sandesh13fr tell me if you need I validate something with these new issues/PR.

Thanks :)

Will do if any.
Thanks.