Overlapping highlights not detected properly (inconsistent)

[Mikko]

OS: Linux
Ver: 6.11

0. Open the attached .pdf
1. Double-click (this is important!) on "four" (4 characters) and highlight them with green.
2. Start selecting with your mouse from (including) the space between "three" and "four" and drag until 2 of the first character of the word "four" are selected. You should get " fo" as your selection. Choose the blue highlight. The selection should be highlighted, but (BUG!) without warning about the overlapping issue.
3. Now double-click (important!) between "u" and "r" in the word "four", thus selecting the whole word. Apply the green color.
4. Repeat step2 but this time select one more letter. The selection should now be " fou".
5. Try to apply the blue highlight. This will give you the "highlights overlap" warning. Cancel.
6. Grab the right selector and make the selection one character smaller " fou" -> " fo". Try to apply blue highlight again. It will also warn you (bug: being inconsistent compared to step2). Cancel.
7. Grab the right selector and make the selection one character bigger " fo" -> " fou". Try to apply blue highlight again. The warning should come again. Cancel.
8. Repeat step6 and try to apply blue highlight. This time it might succeed. If not, repeat steps 7-6-7-6 enough times. For me, it took 1-4 repeats, which was also dependent on restarting the file and starting anew.

This is a really weird bug. I noticed inconsistencies in selection/overlapping feature and I have spent 2 hours trying to find some kind of logic in all this, using spreadsheet and all. And then I found out that the exact same conditions/steps can either show the bug or not. And it just feels like everything influences how, when and whether the bug is going to show itself. What factors seem to be influencing?
- what highlights (colors/styles) are being used as old and as new
- are the words double-click selected or mouse-drag-selected
- is the direction of the selection from the left or from right
- is selection substituted or is the old deleted and a new one started anew
- has there been any restarts of the program/file (restarting does not give the same state, but is simply changing it to something entirely new)
- position of the Moon?

And the above is the best I could come up with. And even that I am not sure just how repeatable it is going to be on others' computers.

This is really different from what I planned to do. My plan was to see the inconsistencies in overlapping selecting warnings, but I can't really do that because the program is contradicting itself. Randomness needs to be fixed first.

But thinking of the time after the randomness fix. Could you please explain the internal logic behind showing the warning or applying the highlight straightaway? Should it always show the warning (because it doesn't) or are there some kind of limits (minimum/maximum number of chars, percentage change, or something else; I just couldn't find the pattern)?

[Kovid Goyal (kovid)]

The purpose of the warning is to try to prevent you losing notes from an
existing highlight. When the selection overlaps only one highlight the
notes are simply migrated to the new highlight so there is no warning.

As for inconsistent detection that will happen if there is a deleted
highlight present. For example when you replace a highlight with a new
one the old one is deleted internally but can still participate in
detection.

This should be cleaned up but its not a real
problem in practice since 1) its uncommon 2) an extra warning is not
that big of a catastrophe.

[Kovid Goyal (kovid)]

Actually, in checking your reproduction scenario I did find one bug that
could cause spurious warnings because of deleted highlights. Fix will be
in next release.

[Kovid Goyal (kovid)]

Fixed in branch master. The fix will be in the next release. calibre is usually released every alternate Friday.

 status fixreleased