feat: allow opening system context menu with double right click

[0kku]

When the app's custom context menu is open, invoking the context menu again causes the system context menu to be invoked instead. This way users can bypass the custom context menu to access the browser's own controls.

Prior art

Works similar to the YouTube player context menu for example.

Some other websites use ctrl/shift/alt + context menu to open the native one instead of the custom one. For example, Google Docs uses shift+right-click. This has the benefit of being able to immediately invoke the intended context menu. The downside is that it requires a keyboard and thus doesn't work on devices with virtual keyboards or none at all, hence why I went with the design described above.

How was this PR tested?

• recruited İspik to test it for me, who confirmed it functions as stated

Screenshots & Screencasts (if appropriate)

Checklist:

• I have carefully read the contributing guidelines
• I have performed a self-review of my own code
• I have made corresponding changes to the documentation if applicable
• I have no unrelated changes in the PR
• I have confirmed that any new dependencies are strictly necessary no ne deps
• I have written tests for new code (if applicable)
• I have followed naming conventions/patterns in the surrounding code

Please declare, if any, LLM usage involved in creating this PR

No

[Arsabutispik]

I have tested this locally and it is working as it's written. We just need confirmation on whatever we want right click action on top of the context menu from the maintainers/UI, UX Team

P.S. Please sign your commits as we can't accept PRs that fail DCO requirement

[0kku]

Currently in the PR it doesn't at all surface guidance for the user and the feature is hard to discover organically. I feel like it would be good to surface it somewhere. Some websites show instructions at the bottom of the context menu on how to invoke the native context menu. However, I'd want to be conscious about creating visual clutter, considering that the feature is unlikely to see use from most users. One option would be to have "Invoke context menu again for more options Got it" at the bottom of the context menu, where the Got it is a button that permanently hides the guidance.

[Pecacheu]

Could you provide any examples of where this is useful? I'm drawing a blank. The only place I use the native context menus is when typing/editing messages, and those spots already use the native context menu because they don't have any custom right-click menu.

[0kku]

Could you provide any examples of where this is useful? I'm drawing a blank. The only place I use the native context menus is when typing/editing messages, and those spots already use the native context menu because they don't have any custom right-click menu.

Pretty much the same reasons one might right click on any website, i.e.

• Searching the web for the selected text (say, someone uses an unfamiliar word or concept)
• Translating a selected text section to a language you understand
• Accessing the browser's read aloud functionality to get TTS functionality
• Opening a longer message in reading mode without including surrounding text elements (for example, for speed reading enjoyers)
• Accessing functionality of any installed browser extensions that add a context menu option
• And any other native browser functionality that one might want to use, such as inspect element, printing, etc.

For comparison, Discord opens the browser's own context menu when you right-click selected text on sent messages and that also pretty much addresses most of the use-cases described above. However, the approach proposed in this PR offers a more comprehensive solution and one which doesn't give inconsistent UX to users who don't need this, unlike Discord.

[Pecacheu]

@0kku I see, that's a good point, I didn't consider browser controls that people might use for reading rather than editing since I haven't used any of those... well aside from copy-paste.

But if that is the main use case, why not do what Discord does and open the native context menu whenever text is highlighted? Come to think of it I think we have an open issue that is somewhat related: #940

I do think Discord's approach makes a lot of sense considering our context menu currently doesn't have any highlighted text related controls in it, so it opening automatically when the user selects text almost feels disingenuous, if that makes sense. Eg. there's a "Copy Text" button in the menu but that copies the entire message, not what you've got highlighted.

There's also the fact that while this works ok for desktop, double-right-clicking on mobile is... very slow and janky. It takes like 5 seconds to long-press, so it's more like 10 to get through to the native menu... Feels like it would be annoying