[Feature] `@run-at context-menu`

[sjehuda]

Feature Description

// @run-at context-menu

The script will be injected if it is clicked at the browser context menu.

Use Case

https://greasyfork.org/scripts/524718-activate-dark-mode

https://greasyfork.org/scripts/522208-explode-thumbs

https://greasyfork.org/scripts/524708-highlight-selected-text

Additional Information

TM and GM for Falkon support this feature.

[CodFrm]

I think GM_registerMenuCommand is a better option than // @run-at context-menu, so no to support context-menu.

[sjehuda]

I agree that the menu is better; yet, the directive of context-menu is particularly convenient to copy and paste a "bokmarklet" and publish it as a script; so, it is advantageous to have it.

[cyfung1031]

I agree that the menu is better; yet, the directive of context-menu is particularly convenient to copy and paste a "bokmarklet" and publish it as a script; so, it is advantageous to have it.

You are right.

The developer CodFrm intentionally removed the support for // @run-at context-menu. He wants ScriptCat to be compatible with most Tampermonkey scripts, but I don't know why he insists to make ScriptCat not to compatible with // @run-at context-menu.

• Note: context-menu is not the same as GM_registerMenuCommand. GM_registerMenuCommand will add the menu options to "popup" too, but context-menu just add the menu options to the context menu

[sjehuda]

@cyfung1031

I would state this argument for the support "content-menu".

Since the success of the movement of USO (Userscripts.org), the browser vendors have plotted to create "webextension" to replace Greasemonkey, instead of standardizing, XUL or XUP.

Greasemonkey still lives!

Since the creation of the gimped "webextension", people have created tools to enhance unique identifiers by analyzing foreign element of their DOM, including "webextensions" that render inside DOM, which is bad (and that is why XUL is preferable for GUI, but that is a different concern).

So, because Greasemonkey has lesser "native means", so to speak, to manifest visual objects, it is often easier to detect Greasemonkey users, provided that JS is enabled.

This is the reason, that I have recently replaced all the custom visual elements of my Greasemonkey extension "Newspaper" (to indicate of operation status of detection of RSS) into "GM.notification" and "GM.registerMenuCommand", so it would be difficult to detect that one utilizes that extension; and in the case of the extension "Explode Thumbs" it is also much better because of "context-menu".

I also intend to replace the custom HTML element of my extension "Paper Clip" into Greasemonkey menus, but that would not work with Falkon, because Falkon is yet to support the menu.

TO CONCLUDE

Unlike DOM, which can be analyzed by servers, GUI can not be analyzed by servers; so, the directive "context-menu" is beneficial and crucial to privacy, also.

[CodFrm]

My thought is that not many scripts use context-menu, and there is a better alternative: GM_registerMenuCommand, Refactoring is also quite easy. so can gradually shed some of Greasemonkey historical baggage.

It seems i still need to add context-menu. I give up the struggle—ScriptCat doesn’t have that much influence at this stage.

Maybe i can add an ESLint rule to flag context-menu as an error.