Blue underline and higlighting after comment deleted


After I have got rid of a comment (highlights entire text yellow) the comment and the yellow highlight disappears, but as soon as I start to edit that bit of text it highlights and underlines it in blue. Anyone got any ideas how I can stop this? It has only just started happening and I have been usign the software for years.



This appears to be a long-term bug. I’ve noticed the same issue (in 2023 using 3.3.3). When I ddelete the comment in the sidebar, the related text appears in its normal font, but if I edit that bit of text (whatever had been highlighted by the comment), I get blue, underlined text.

I had tried using the text color function, but it does not solve the problem, nor does the underline function.

To remove it, I found I had to delete that text and possibly any space(s) on either side of it, and type the desired text back in. This is a lame way to fix the text.

This issue should be looked into.

I cannot reproduce this. Can you please provide full instructions? I tried:

  1. Delete a comment from the inspector.
  2. Select the text that previously had the comment applied.
  3. Type over it.

I also just tried clicking at the end of the text that had the comment applied and typing.

Neither resulted in blue/underlined (linked) text.

All the best,

Hello, KB.

I wasn’t able to recreate it when I tried just now with the steps you list; however, it might be the issue has to be in conjunction with other functions I use, such as Text Tidying to remove cross-throughs, along with font color changes.

Yes, there might be a particular sequence that is required to trigger it. Comments have links associated with them, which allows clicks on them to open the associated comment in the inspector. It sounds as though the link is being left in the typing attributes when they are removed - which is strange because my code is specifically removing both the comment and the link, so it shouldn’t be possible for the link to linger without the comment.

If you can find a specific situation in which it occurs, please let me know. Without being able to reproduce it, and without there being anything obvious in the code (i.e. it must be something subtle in the code that I’m missing), it’s difficult to find the problem. Once we can reproduce it, we’ll have some clues to go on.

Thanks and all the best,

Hi KB,

It’s doubtless that a combination or sequence of tools create the situation. I can’t spend time trying to recreate it from scratch, though I did try. It happens in a large, multi-chapter book that I have been working on for a while. I’ve been using combinations of tools to edit and clean up the text, such as text tidying to remove strike-outs, converting to smart quotes, and changing text color to remove any assigned colors (choosing no color).

Also, the first note about this is from 2020, so this issue has been around for a while.

Hope this points you in the right direction.

Thanks for checking it out. :slight_smile:

Could it be specific to the OS? This sequence is working reliably for me to reproduce the issue on Catalina 10.15.7 with the default prefs, but I haven’t triggered it on any other system yet. (In all cases I’ve been testing 3.3.4 16237.) That makes it seem likely to be the specific environment, but oddly I’m still getting it on Catalina even in a test user account. So maybe it’s something in the system settings that I did enable there in a basic set up—for the most part though I haven’t messed with any of that.

At any rate, I’m wondering what OS versions others seeing this are on.

Here’s what is working consistently for me on Catalina; maybe someone else will be able to reproduce it with these steps:

  1. In a new blank project, create a new document and type “This is a test”
  2. Apply a comment to “test” (just leaving the default text is fine)
  3. Return focus to the editor and add a space and “more text” at the end (so it now appears as “This is a test more text”, with the comment on test only)
  4. Delete the comment by clicking its “x” in the inspector (or opening it as a popup and clicking Delete)
  5. Position the cursor in the center of “test” between e and s
  6. Press the space bar

The word splits and both “te” and “st” are hyperlinked to the now-deleted comment. (They each appear as a regular link in the editor, not a comment; but it is a link to the comment, per the RTF.) In other cases with different text or depending on the position of the insertion point within the text, only part of the text may end up linked, but I was able to get it happening regularly in testing.

The key points seem to be moving the insertion point into the previously-linked text (rather than selecting it) and then typing with a space or other terminating character (e.g. a period or question mark).

1 Like

I followed those instructions and exactly and am not seeing it on Sonoma (unfortunately I don’t have a 10.15 machine).

It’s very strange that it should be happening, too, because my code is set up so that whenever a comment is removed, the link is removed too. This is checked right in the text during editing - any time a text change is made, if it detects a comment has been removed, the link is also removed. But it’s even stranger than that, because it sounds as though the link is being removed, but that it’s then being added back when you type in the word, even though there is no longer a comment there. But when you click into text after the selection was elsewhere, the typing attributes are taken from the previous character, so if the link isn’t present when you click into it, I have no idea where the link is coming back from!

Given that it isn’t happening in Sonoma, it sounds as thought it might have been a bug in an earlier version of macOS that Apple has fixed. It’s an odd one, though, because normally I can work out how this sort of thing might happen in theory, but here I can’t!

Hi MimeticMouton,

Yes, in fact, I’m using MacOS 10.15.7. My Scrivener version (until I update later today or tomorrow) is 3.3.3 (15931). I had not noticed this issue until recently, perhaps related to moving to 3.3.3.

Perhaps other MacOS and Scrivener versions are not seeing this issue.

Thanks for this thorough test.