No selected text -> word clicked is selected

[tDeContes]

Background

It's annoying to always have to select text (with double-click for one word) before right-click.
The spell checker needn't that, I can right-click a word without having to select it before.

Proposed solution

When there is no selected text, please consider that the word which is clicked is selected, instead of do nothing.
Please consider ' as a letter (ie It's as 1 word, not 2 -- as it's already done by Capitalize Each Word, but not by double-click!).

Additional context

I don't know if it's allowed by the API. Let me know please. :-)

[tdulcet]

Thanks for the feature request! Interesting idea.

I suspect most users are using the Unicode font conversion feature on multiple words at once, so this proposed feature would not help. In addition, this is not directly supported by the WebExtention APIs, which only provides the selected text, not the word the user's cursor happened to be over when they opened the context menu. There are other ways of opening the context menu than just right clicking.

Anyway, the add-on already has a content script to do the Unicode autocorrection, so it may be able to manually select the word with the JS Selection and Range APIs when the user opens the context menu. However, this would affect other add-ons as well and may interfere with some websites not expecting that behavior, so if we were to implement this functionality, it would need to be disabled by default.

Yes, I used a complex regular expression to handle the apostrophe and a few other edge cases for the "Capitalize Each Word" feature. One may be able to reuse that here or maybe use the new JS Intl.Segmenter API, but it is currently only supported in Firefox Nightly/Thunderbird Daily.

[tDeContes]

Thanks for the feature request! Interesting idea.

I suspect most users are using the Unicode font conversion feature on multiple words at once, so this proposed feature would not help.

I hate having to hit the Shift key while I'm typing, so Unicodify is very useful for that. Capitalize Each Word most of time, Lowercase for undo, Uppercase for acronyms. (I'd prefer have them in this order, but no matter.)
For me, change casing is a must, and should almost be part of the apps core, like Copy Link Text. Do you thing we are so few in my case ?

In addition, this is not directly supported by the WebExtention APIs, which only provides the selected text, not the word the user's cursor happened to be over when they opened the context menu.

OK, does it provide the location (relative to the text) of the right-click, nevertheless ?
It will be a bit of work more, I understand.

There are other ways of opening the context menu than just right clicking.

Oh good ? I don't know them, what are they ?

Anyway, the add-on already has a content script to do the Unicode autocorrection, so it may be able to manually select the word with the JS Selection API when the user opens the context menu.
However, this would affect other add-ons as well and may interfere with some websites not expecting that behavior,

Do you think that would not be possible to get the word and replace it without selecting it first ?

so if we were to implement this functionality, it would need to be disabled by default.

No pb to have it as an option :-)

Alternative: Make core / an other extension to select the word at right-click. It seems to make sens, given that in this context, spell checker and change casing are applied to the word, so it wouldn't be crazy from the user point of view.
I can investigate for that.

Do you know cases where this would be a pb ?

Yes, I used a complex regular expression to handle the apostrophe and a few other edge cases for the "Capitalize Each Word" feature. One may be able to reuse that here or maybe use the new JS Intl.Segmenter API, but it is currently only supported in Firefox Nightly/Thunderbird Daily.

Since you already code it, you can reuse it now and simplify the code later, when Intl.Segmenter will be available in the current version of apps. :-)
Alternative: You could implement the word like double-click for now, and wait for Intl.Segmenter to implement '.

[rugk]

Do you thing we are so few in my case ?

What exactly is your use case? I did not quite got it. I mean, what is a Maj key, to start with?

[tDeContes]

I did not quite got it. I mean, what is a Maj key, to start with?

Sorry, I speak English like a French pig (which I am)! :-)

I edited my post, so you can remove yours if you want.

[tdulcet]

OK, does it provide the location (relative to the text) of the right-click, nevertheless ?

The WebExtention API provides a lot of information, but not much that would be helpful here. For this, one would need to use the JS contextmenu event, which does provide the needed information. Hopefully, this would fire before the WebExtention API, so that the latter would see the newly selected text.

Oh good ? I don't know them, what are they ?

Some keyboards have a context menu key. Typically, most assistive technology also has a method to open the context menu.

Do you think that would not be possible to get the word and replace it without selecting it first ?

Sure, but that is not how this add-on currently works and it would add significant complexity. If you want that functionality, it may be best to create a dedicated add-on.

Do you know cases where this would be a pb ?

I do not believe this would cause any incompatibilities, but note that programmatically selecting a user perceived word can be trickier than it sounds, as it can span multiple text nodes in a ContentEditable Div, especially if formatting is involved. When using the JS Selection API, there is a provided function that makes this easy.

Since you already code it, you can reuse it now and simplify the code later, when Intl.Segmenter will be available in the current version of apps. :-)

That is likely what I would recommend doing. Pull requests are welcome!

[tDeContes]

OK, does it provide the location (relative to the text) of the right-click, nevertheless ?

The WebExtention API provides a lot of information, but not much that would be helpful here. For this, one would need to use the JS contextmenu event, which does provide the needed information. Hopefully, this would fire before the WebExtention API, so that the latter would see the newly selected text.

OK. Do you think that would not be too hard to code ?

Oh good ? I don't know them, what are they ?

Some keyboards have a context menu key. Typically, most assistive technology also has a method to open the context menu.

OK. Is it possible to know whether context menu was opened by right-click or otherwise ?
If yes, in otherwise case we have to ignore mouse position, and we have to decide to do noting or to run the process with the carrot position.

Do you think that would not be possible to get the word and replace it without selecting it first ?

Sure, but that is not how this add-on currently works and it would add significant complexity. If you want that functionality, it may be best to create a dedicated add-on.

OK, then forget it.

Do you know cases where this would be a pb ?

I do not believe this would cause any incompatibilities, but note that programmatically selecting a user perceived word can be trickier than it sounds, as it can span multiple text nodes in a ContentEditable Div, especially if formatting is involved. When using the JS Selection API, there is a provided function that makes this easy.

Is the JS Selection API available in the current version of apps ?
If yes, it's fine. :-)
If not, let me know ...

Since you already code it, you can reuse it now and simplify the code later, when Intl.Segmenter will be available in the current version of apps. :-)

That is likely what I would recommend doing.

If the alternative where you implement the word like double-click would make it easy enough to allow you to write it now, it would be a significant improvement for me. :-)
Anyway, more improvements can be made later.

Pull requests are welcome!

I'm sorry, I don’t know write extensions, I’m an Ada dev.

[tdulcet]

OK. Do you think that would not be too hard to code ?

No, I would not expect it to be too difficult, probably less than ~100 lines of code.

OK. Is it possible to know whether context menu was opened by right-click or otherwise ?
If yes, in otherwise case we have to ignore mouse position, and we have to decide to do noting or to run the process with the carrot position.

Yes, it looks like this should be possible. I would think it would be best to use the caret position in that case.

Is the JS Selection API available in the current version of apps ?

Yes, as the link I provided shows, it is a standard JS API that is been available in all browsers for more than a decade.

If the alternative where you implement the word like double-click would make it easy enough to allow you to write it now, it would be a significant improvement for me. :-)

We can consider adding this for the next update.

[tDeContes]

If the alternative where you implement the word like double-click would make it easy enough to allow you to write it now, it would be a significant improvement for me. :-)

We can consider adding this for the next update.

Do you mean the next after the one with code casing?
Any idea of time ?

(I admit that I miss this feature, hope I'm not being too pushy.)

[tdulcet]

Do you mean the next after the one with code casing?
Any idea of time ?

I was referring to the update with the coding cases, but it could be the next one after that depending on when someone finds the time to implement this. As I said, PRs are welcome if anyone wants this sooner...

We do not have a set release schedule for this add-on, so we release a new version whenever there has been enough changes to justify the update. Unless @rugk wants to publish a new version sooner, I will probably do this sometime before the Firefox/Thunderbird 128 ESR upgrade, as this is typically when I update all of my add-ons.

[tDeContes]

Do you mean the next after the one with code casing?
Any idea of time ?

I was referring to the update with the coding cases, but it could be the next one after that depending on when someone finds the time to implement this. As I said, PRs are welcome if anyone wants this sooner...

Since I can't do it, if you can do it before the next update, with the coding cases, that would be really fine! :-)

Please don't care about words, because even if I think I would prefer I'm to be 1 word, I'm not sure about the rest: Recently I had to write Ctrl-Alt-Right/Left so I was happy to be able to double-click on each. :-)