Context menu not showing "Unicodify – Text transformer"

[jjpcorriveau]

Bug description

I select a text then right-click but "Unicodify – Text transformer" doesn't appear in the context menu.

Steps to reproduce

1. I restarted Thunderbird.
2. I reinstalled the add-on.
3. I restarted TB.
4. Still the same problem.

Actual behavior

Expected behavior

Reproducibility on test website

• Issue is reproducible on https://rugk.github.io/unicodify/ for text input fields.
• Issue is reproducible on https://rugk.github.io/unicodify/ for textarea fields.
• Issue is reproducible on https://rugk.github.io/unicodify/ for ContentEditable Divs.
• Issue is not reproducible on https://rugk.github.io/unicodify/

System

Operating system and version: Linux Mint 20.2
Browser and version: Microsoft Edge 112
Add-on version: 0.5

Possible solution

[rugk]

@jjpcorriveau A screenshot would be very helpful here, if possible.

[rugk]

Browser and version: Microsoft Edge 112

And could you please put your Thunderbird version here, I guess the template is a little misleading here hehe…

[jjpcorriveau]

@jjpcorriveau A screenshot would be very helpful here, if possible.

[jjpcorriveau]

Browser and version: Microsoft Edge 112

And could you please put your Thunderbird version here, I guess the template is a little misleading here hehe…

Thunderbird 91.10
The context menu shows 'The Emoji Picker' just fine, by the way.

[tdulcet]

I select a text then right-click but "Unicodify – Text transformer" doesn't appear in the context menu.

Thanks for the bug report. This is actually a known issue in Thunderbird, which is why the add-on is marked as "experimental". It is also documented in the ATN listing:

unicodify/assets/texts/en/atnDescription.html

Line 31 in e1e07d2

⚠️ Note that context menu does NOT currently work in Thunderbird's compose body because of <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=1716976">Bug 1716976</a>.

Hopefully bug 1716976 will be fixed soon... If you have a BMO account, it would be helpful if you could click the "Follow" button on the top of that bug, so they will prioritize fixing this.

[rugk]

I just tried it by myself, so is it also known/reported that the text you select in the subject line is then not actually being replaced in the subject line, but pasted into the body?

Thunderbird-Unicodify-Test-ContextMenu.mp4

[jjpcorriveau]

I just tried it by myself, so is it also known/reported that the text you select in the subject line is then not actually being replaced in the subject line, but pasted into the body?

Thunderbird-Unicodify-Test-ContextMenu.mp4

Yes. That's it. I had not noticed this behaviour. Context menu shows "Unicodify – Text transformer" only in the subject line, never the body of the email. Then, selected text from the subject gets pasted in the body.

[tdulcet]

I just tried it by myself, so is it also known/reported that the text you select in the subject line is then not actually being replaced in the subject line, but pasted into the body?

Yes, that is also a known issue, see rugk/awesome-emoji-picker#49 (comment). In short, I filed bug 1641575, but they marked it as WONTFIX.

I have some changes locally that would copy it to the clipboard in this case as a workaround. However, we would likely need to also display a notification to the user so they would know to then hit Ctrl + V, so the change would require two additional permissions. I would be happy to create a PR, if this would make it easier for someone...

[rugk]

Hmm that could be a feasable workaround, however, I doubt this is in any case not that useful. Especially, if it is only for the subject.

Given the main bug is soon to be fixed (see #73 (comment)), the main issue is at least solved then. Anyway yeah hmm… having a notification and a clipboard copy would be useful.

[tdulcet]

I am not sure if the main issue "is soon to be fixed" given that I filed bug 1716976 over a year ago...

Anyway, this proposed change was more to workaround the issue in your above video: #73 (comment). Technically it would work for all the fields in the compose window, although I suspect it would only be useful for the subject.

[tdulcet]

I have some changes locally that would copy it to the clipboard in this case as a workaround.

I added this workaround to #72 and published it on ATN as version 0.5.1. I also moved that warning about the context menu not working in Thunderbird's compose body up more towards the top of the description on ATN and I added it to the "Developer Comments" section.

[tdulcet]

Hopefully bug 1716976 will be fixed soon...

They finally fixed this bug and it will appear in Thunderbird 111! Hopefully they will also uplift the fix to Thunderbird 102...

[tDeContes]

Hopefully bug 1716976 will be fixed soon...

They finally fixed this bug and it will appear in Thunderbird 111! Hopefully they will also uplift the fix to Thunderbird 102...

That's not fine, guys !! ...

It works for a msg whose length is no more than the height of the composer window.

If you write a longer msg, then it still works at the beginning of the msg, the one you can see without scrolling.
But if you scroll to go in the hidden part, look, it doesn't work again !

Will you re-open the issue, or should I create a new one ?

[tDeContes]

I just tried it by myself, so is it also known/reported that the text you select in the subject line is then not actually being replaced in the subject line, but pasted into the body?

Yes, that is also a known issue, see rugk/awesome-emoji-picker#49 (comment). In short, I filed bug 1641575, but they marked it as WONTFIX.

What about the compose.setComposeDetails and getComposeDetails he told ? Doesn't it allow to replace text in the subject line ?

I have some changes locally that would copy it to the clipboard in this case as a workaround. However, we would likely need to also display a notification to the user so they would know to then hit Ctrl + V, so the change would require two additional permissions. I would be happy to create a PR, if this would make it easier for someone...

Thank you very much for have done this, it really helped me ! :-)

[tdulcet]

If you write a longer msg, then it still works at the beginning of the msg, the one you can see without scrolling.
But if you scroll to go in the hidden part, look, it doesn't work again !

Interesting, thanks for the bug report! I was able to reproduce the issue, but it is a Thunderbird bug, so I filed bug 1882725. I can reopen this issue while we wait for Thunderbird to fix it.

What about the compose.setComposeDetails and getComposeDetails he told ? Doesn't it allow to replace text in the subject line ?

That allows changing the entire subject of the message, but add-ons have no way to determine where the selected text occurs in the subject or where the caret is.

Thank you very much for have done this, it really helped me ! :-)

No problem, I am glad the workaround was helpful for you.

[tDeContes]

If you write a longer msg, then it still works at the beginning of the msg, the one you can see without scrolling.
But if you scroll to go in the hidden part, look, it doesn't work again !

Interesting, thanks for the bug report! I was able to reproduce the issue, but it is a Thunderbird bug, so I filed bug 1882725. I can reopen this issue while we wait for Thunderbird to fix it.

Thank you for reactivity. :-)
Hope Thunderbird has the same ...

What about the compose.setComposeDetails and getComposeDetails he told ? Doesn't it allow to replace text in the subject line ?

That allows changing the entire subject of the message, but add-ons have no way to determine where the selected text occurs in the subject or where the carrot is.

(carrot = cursor ?)

OK, I see that Geoff Lankow didn't answer you. Maybe insist, explaining more what you want to do and that setComposeDetails / getComposeDetails does not allow ?

Thank you very much for have done this, it really helped me ! :-)

No problem, I am glad the workaround was helpful for you.

This makes the 2nd issue non-critical, unlike the 1st.

[tdulcet]

Thank you for reactivity. :-)
Hope Thunderbird has the same ...

No problem. Thunderbird typically takes a while to fix bugs, but hopefully they will be able to fix it in time for Thunderbird 128 later this year.

(carrot = cursor ?)

Yes, the caret is the blinking cursor when typing.

OK, I see that Geoff Lankow didn't answer you. Maybe insist, explaining more what you want to do and that setComposeDetails / getComposeDetails does not allow ?

That bug was more focused on the autocorrection, but I am not sure if there is a great solution for this problem in general.

For the Unicode font conversion feature of this add-on, one could use setComposeDetails/getComposeDetails as long as the selected string only occurs once in the subject. If it occurs more than once, it would be ambiguous as to which one to replace. This would also reset the position of the caret (likely to the end of the line). If you think this would be an improvement over the current workaround of copying the transformed text to the clipboard, then we could consider it for the next version of the add-on.

[tDeContes]

Thank you for reactivity. :-)
Hope Thunderbird has the same ...

No problem. Thunderbird typically takes a while to fix bugs, but hopefully they will be able to fix it in time for Thunderbird 128 later this year.

Ouf ! Have they no means to make it earlier ? How much versions between the current and 128 ?
(Considering that's a bug, not an improvement !)

OK, I see that Geoff Lankow didn't answer you. Maybe insist, explaining more what you want to do and that setComposeDetails / getComposeDetails does not allow ?

That bug was more focused on the autocorrection, but I am not sure if there is a great solution for this problem in general.

For the Unicode font conversion feature of this add-on, one could use setComposeDetails/getComposeDetails as long as the selected string only occurs once in the subject.

If it occurs more than once, it would be ambiguous as to which one to replace.

There would be the same problem !

This would also reset the position of the carrot (likely to the end of the line).

This should not be a problem, since we have to select the text, and it is not at the place where we need the carrot for the next modification.

If you think this would be an improvement over the current workaround of copying the transformed text to the clipboard, then we could consider it for the next version of the add-on.

I prefer you to relaunch Thunderbird on that pb, and wait to be able to do this cleanly. :-)

(Note that I would expect the selection on right-click working also for these fields.)

[tdulcet]

Ouf ! Have they no means to make it earlier ? How much versions between the current and 128 ?
(Considering that's a bug, not an improvement !)

Thunderbird currently only has a single Web Extension developer and he is overworked, so it takes time for add-on related bugs to be fixed... It is of course possible that this could be fixed sooner, but unlikely considering it is not a regression (it never worked). Thunderbird follows the Firefox ESR release schedule, so they have one major release per year, typically sometime between June and July, and then there is a gradual automatic upgrade process after that which concludes between September and October. See the calendar for the exact dates this year: https://whattrainisitnow.com/calendar/.

(Note that I would expect the selection on right-click working also for these fields.)

This is the same problem as with the autocorrection, without the ability to run the standards JS events in those fields, there is not much we can do.

[tDeContes]

Ouf ! Have they no means to make it earlier ? How much versions between the current and 128 ?
(Considering that's a bug, not an improvement !)

Thunderbird currently only has a single Web Extension developer and he is overworked, so it takes time for add-on related bugs to be fixed... It is of course possible that this could be fixed sooner, but unlikely considering it is not a regression (it never worked).

True, that's not a regression!

Then, if it can be fixed within 6 months, it's fine. :-)

(Note that I would expect the selection on right-click working also for these fields.)

This is the same problem as with the autocorrection, without the ability to run the standards JS events in those fields, there is not much we can do.

Anyway, thanks to your workaround, (from my point of view) it's low-priority. :-)

[tdulcet]

True, that's not a regression!

It turns out it was a regression, just an old regression from 3 years ago that no one noticed. Anyway it is now fixed in Thunderbird 125 Daily, so hopefully they will uplift it to 115 ESR in the next month or so...

[tDeContes]

True, that's not a regression!

It turns out it was a regression, just an old regression from 3 years ago that no one noticed. Anyway it is now fixed in Thunderbird 125 Daily, so hopefully they will uplift it to 115 ESR in the next month or so...

Good news, thanks for the info!
It would be nice to be available in Ubuntu LTS soon!