// @run-at context-menu

[quoid]

Allows users to set // @run-at context-menu which will create a right click context menu that when clicked will inject the file's javascript.

related: #64

[quoid]

Some notes in case anyone comes across this:

The "alternative" implementation would have been having the background script request all files that have @run-at context-menu and applying that context menu item to all applicable urls with the documentUrlPatterns value. Most of the functionality regarding context menu item creation and removal could be handled in the background page.

However, there seems to be some downsides to this approach :

1. Can only use @match
2. @exclude-match implementation seems impossible at the current time

Some benefits of the "alternative" implementation:

1. Dealing with SPA is easier since the match pattern will apply (if applicable) automatically to subsequent new pages

The approach so far has been to handle this within the content script. This requires "on demand" creation of context menu items for each page visited. So when a user visits a page, it checks if there is a matching userscript with @run-at context-menu and create menu items as needed.

This approach is not without its own idiosyncrasies.

1. There are a lot of context menu items created.

• imagine there's one script, CM-Script01.js that has @run-at: context-menu. The match value is *://*/* (targets all urls)
• If the user has 42 tabs opened, there are 42 unique context-menu items. Each context-menu item is scoped to unique urls however. To the user, there is 1 context menu item per page.
• If there is a hard limit on the amount of context menu items, even spread across multiple pages, depending on that limit, it could be hit.

2. Hacky method of dealing with SPA url changes.

• Since SPA paging (url changes) doesn't cause the content script to re-inject and context menu items are scoped directly to the url that they are created for, there has to be a way to check when an SPA pages.
• The current implementation stores the currentUrl from page load and adds an event listener to the "contextmenu" event. If currentUrl != window.location.href when this event fires, it "reprocesses" the context-menu scripts.
• This means sometimes a user might have to trigger the context menu twice before seeing the item.

The biggest benefit of the current implementation is that exclusionary or negative matches are possible.

The benefits of the approach so far is that the user can utilize @include and @exclude/@exclude-match. If possible, I'd like @run-at context-menu userscripts to function exactly like "normal" userscripts and utilizing the approach so far seems closer than the "alternative" approach mentioned above (which has more restrictions on use).

Summary:

Current implementation has some UX issues like dealing with SPAs and complex implementation.

Alternative implementation will restrict options on how userscripts with @run-at context-menu can function.

I am unsure which approach is best at the current time.

[quoid]

in beta