Desktop: Fixes #11617: Links from imported notes from OneNote were being wrongly rendered #11618
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…x-links-broken-when-have-multiple-styles
…x-links-broken-when-have-multiple-styles
pedr
added
bug
pedr
changed the title
pedr
changed the title
pedr
commented
Jan 9, 2025
| indices.remove(0); | ||
| styles.pop(); | ||
| } | ||
|
|
||
| // Probably the best solution here would be to rewrite the render_hyperlink to take this | ||
| // case in account, backtracking if necessary, but this will do for now |
…n-have-multiple-styles
…ple-styles' into fix-onenote-link-on-start-paragraph-broken
…start-paragraph-broken
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Fixes #11617
Summary
Sometimes, when the first element of an Oultine (paragraph) is a link it will, be wrongly rendered as seen in the image bellow. It seems only to happen when the link is the first element, but I could not recreate the problem from scratch on a new note, so I'm using the content from the faulty note that I found.
In the end, I could not figure out why this was happening, but I created a fix that takes cases like this into account and properly renders links like they are supposed to:
Before / After fix
Important
I think the best implementation to fix this problem would be rewrite how
render_hyperlinkworks, it seems like to me that the proper why to implement this would be to render everything after the\u{fddf}character as a hyperlink until we find the last element or backtrack everything and apply the correct styles if turns out that the text doesn't belong to a link.This seems like the proper solution, but it is also more work, so I went with the quick fix for now.
Testing
I added an automated test based on a faulty note that we found. I could not recreate the issue from scratch.