When an XNote window is open, delete context menu deletes that XNote instead of the selected note

[goozak]

XNote++ v4.3.32 (updated Oct. 8 2024) on Thunderbird 128.7.0esr (64-bit) on Windows 10 Thunderbird account is using a Microsoft Exchange server with IMAP

It's been happening randomly for a while, but I think I finally figured how to reproduce it...

When deleting an XNote via the context menu, the note from the email I right-clicked on stays there, but another note gets deleted.

Here's how to reproduce it:

• I have a list of three emails, A B & C.
• I set an XNote on email A.
• I set one on email B.
• I set one on email C.
• I select email B by just clicking on it.
• I display the context menu of email A, and select "Delete note".
• The note from email C ⁉ is deleted.

The Delete menu item seems to always delete the most recently created/updated XNote, no matter which email was actually clicked-on to display the context menu.

[opto]

can you test the following:

Thunderbird has two ways to select messages. One can rightclick on message 2 while message 1 is still silently selected. In that case, maybe message 1 xnote is deleted.

You can distinguish by the selected email being light blue or dark blue. What happens if it is selected dark blue? Then, the correct xnote should be deleted.

[goozak]

Even if I right-click the directly selected message (dark blue), the note deleted is the one I previously edited.

The only way to be sure is to edit a note and delete it from the bottom icons, which also provides a confirmation, absent from the message context menu.

[opto]

the code uses this: hdrForFirstSelectedMessage

Can it be that several messages are selected?

[opto]

and here it works (!?):

create a new XNote close XNote window

click another message with XNote right click to delete

the correct message is deleted here (Win 11, no other adons)

[goozak]

I can reproduce the issue with all my other extensions disabled.

Here's a video:

https://github.com/user-attachments/assets/1b377bdf-e9bd-4122-a4b4-fb2c477666a8

[At the end, it shows a bug with the 'tooltip' text, where the previous value remains while being overwritten with the new one.]

While recording this, the Error Console showed these (the stack trace is the same for all 4 errors:

sendRemoveListener on closed conduit [email protected] ConduitsChild.sys.mjs:122:13
    _send resource://gre/modules/ConduitsChild.sys.mjs:122
    removeListener resource://gre/modules/ExtensionChild.sys.mjs:673
    removeListener resource://gre/modules/ExtensionChild.sys.mjs:929
    register chrome://extensions/content/child/ext-storage.js:165
    removeListener resource://gre/modules/ExtensionCommon.sys.mjs:2959
    revoke resource://gre/modules/ExtensionCommon.sys.mjs:2981
    close resource://gre/modules/ExtensionCommon.sys.mjs:2986
    unload resource://gre/modules/ExtensionCommon.sys.mjs:1019
    close resource://gre/modules/ExtensionContent.sys.mjs:1067
    destroyed resource://gre/modules/ExtensionContent.sys.mjs:1140
    observe resource://gre/modules/ExtensionContent.sys.mjs:1163
	
sendRemoveListener on closed conduit [email protected] ConduitsChild.sys.mjs:122:13
sendRemoveListener on closed conduit [email protected] ConduitsChild.sys.mjs:122:13
sendRemoveListener on closed conduit [email protected] ConduitsChild.sys.mjs:122:13

[opto]

it only deletes the correct note when it is clicked and dark blue. When it is only light blue, i do not get the correct index in the list

[goozak]

Here's a recording for that. The previously edited note is still the one deleted.

https://github.com/user-attachments/assets/cad85547-c431-4133-bb5e-516bac098cfa

If I use the context menu on a NON-dark-blue message to add a Tag, for example, it adds it to the expected message. It may be a bug only for extensions...

[opto]

TB has two ways of selecting: click/dark blue and hover/light blue ,as you show. This feature works on click.

[goozak]

OK, but you can see in my previous video that the wrong note is still deleted when I right-click on a dark blue selection.

[Chealer]

Thank you very much @goozak , I can reproduce this with XNote++ 4.3.38 on Thunderbird 128.8.0 (Windows 11). I suggest retitling:

Deleting a note using the context menu may actually delete the wrong note

[opto]

@goozak: left click note first, then right click-> delete. Does it delete the correct note then?

[goozak]

@opto

Does it delete the correct note then?

Not if I modify a different note beforehand.

Note that selecting the "Modify" context menu, then the "Delete" button there will delete that correct note. This is from memory, though, because, since I upgraded to TB 136, XNote++ is flagged as incompatible, thus disabled.

[Chealer]

@opto : If you asked me, I would have replied it deletes the correct note then.

While testing this, on several occasions, trying to delete a note via the context menu failed, quietly. Nothing happened (as far as I can see anyway―I hope I didn't lose any important note). There was no error, either displayed or logged. I also got this logged in the console at some point:

syncdel Error: Could not establish connection. Receiving end does not exist. moz-extension://e7cf6b59-f92e-45ad-84ed-13708b2edaac/xn-background.js:359 xn-background.js:363:32

@goozak: Which Modify context menu are you referring to?

[goozak]

@Chealer

Reminder : This bug happens after a note was added / edited. If you switch folder, then delete, it will work.

trying to delete a note via the context menu failed, quietly

You need to first click on a different row, to update the display - the column refresh is not 'automatic'. You think nothing happened, but then it's the note several emails down that's been deleted.

Which Modify context menu are you referring to?

The XNote contextual menu, "Modify note" just above "Delete note"

[Chealer]

@goozak:

Reminder : This bug happens after a note was added / edited. If you switch folder, then delete, it will work.

Ah, thanks, that's interesting. It would be helpful to specify that in the description.

trying to delete a note via the context menu failed, quietly

You need to first click on a different row, to update the display - the column refresh is not 'automatic'.

Thanks anyway but I'm aware of that.

You think nothing happened, but then it's the note several emails down that's been deleted.

I reproduced this many times more and can confirm what I was saying. In fact, it's easy to reproduce. Even if you look at the XNote++ directory, nothing disappears. There is truly no note deleted.

[Chealer]

Note that selecting the "Modify" context menu, then the "Delete" button there will delete that correct note.

I figured out what @goozak meant: Deletion works fine when deleting from the note popup/rectangle using the button with a red icon. That does match with my experience, since that's always how I delete notes and I never noticed this bug (before seeing this report).

This bug is only about deletion from the context menu.

[Chealer]

Here is a scenario which simplifies reproduction steps and clarifies the problem:

1. Open a folder with a mail N which has no note and a mail O which has a note without value.
2. Select mail N
3. Add a dummy note to mail N
4. Bring up the context menu on mail O via a secondary click (without selecting it)
5. Select "Delete note"
6. The note from email N is deleted.
7. Bring up the context menu on mail O via a secondary click (without selecting it)
8. Select "Delete note"
9. Nothing happens (no note is deleted).

The last 2 steps can be repeated.

[opto]

for me, that only happens when:

the recently edited XNote window is still open and visible. Is that what you observe?

If the recently edited XNote window is not open (another email was clicked/selected without XNote), then the correct XNote is deleted.

Same at your end?

[Chealer]

No @opto; even if the note is closed and entirely invisible (neither the note, its preview nor the column), the wrong note is deleted.

[opto]

you can try this, here,it solves the problem: https://github.com/xnotepp/xnote/releases/tag/v4.5.39

[goozak]

Indeed! Fixed. 😄

[Chealer]

Thank you very much @opto, I confirm.