emvaized/circle-mouse-gestures

Menu doesn't show up in certain website frames

Closed this issue · 10 comments

robertwhitlock3 commented

Hi emvaized,
I was looking for an alternative to mouse gestures, and I'm really liking the look and feel of this extension.

One thing I've noticed though, is that the menu doesn't always show up when attempting to open the menu on every website frame.
Some examples I've seen:

In some cases, right clicking on a different element of the page will pop up the menu (i.e. the header bar of the page). I've seen other mouse gestures extensions struggle on local pages as well.

I'm running Brave: Version 1.39.122 Chromium: 102.0.5005.115 (Official Build) (64-bit)], but issue also occurs when using Chrome [Version 102.0.5005.115 (Official Build) (64-bit)]
Running on Microsoft Windows 10 Pro [10.0.19044 Build 19044]

Sorry if that's not a lot to go off, I can try to keep track of further examples as I encounter them

emvaized commented

Hi Robert,
Due to security limitations, browser extensions are prohibited to run on some pages, such as New tab page, service browser pages (such as Settings page), and browser extensions store (chrome.google.com/webstore/category in your case). There's nothing I can do about it, as it is browser's policy – and honestly, it is better to leave it that way.

Also this extension may not work, or work unexpectedly, over in-page iframes or on websites which override system context menu and provide their own. In this case each 'problematic' page should be considered separately, and sometimes the issue can be fixed or provided with a work-around, and sometimes it can't – either way, it needs more details from you where exactly you have the issue.

robertwhitlock3 commented

Hi emvaized,
Thanks for getting back to me. The scenarios you've mentioned sound like they describe exactly where I've encountered this.

Using some quick google-fu, some examples that display this behaviour are:

I've just tested and can confirm that CrxMouse Chrome Gestures can draw over any of these elements (except for - interestingly - the ad in the iFrame of the w3schools page.)

emvaized commented

Actually, the problem with in-page iframes is the easiest one – it was already requested previously for my another extension, Selecton, and it now works just fine in iframes with a simple manifest rule.

With this extension, however, I have not enabled it for 2 reasons:

  1. Each iframe on page actually represents a separate page and context, which may lead to unwanted behavior. For example, when user wanted to trigger 'Scroll up' action on the main page, and instead scrolls the iframe, or when user calls 'Copy URL' action, and extension copies the iframe's URL instead of page's URL. Iframes sometimes are embedded very seamlessly, and user may not even be aware that they actually clicked on an iframe
  2. For the same reason, when circle was triggered near the edge of iframe, it gets cutted by them, as can be seen here – when I manually enabled the iframe support:

illustration for iframe support problem

Mainly because of these 2 reasons I decided to not include iframe support in this extension yet

robertwhitlock3 commented

Interesting. For your second point, having a little play, I can see other extensions run into the same issue:
image

So the overlay is drawn over the frame rather than over the page.

To the first point, if it's not a massive difficulty to enable, would it be possible to add this functionality behind a configuration toggle, to allow users to opt in? (For my use case, I'm only using tab level gestures - left/right/duplicate/close/reload and reopen closed tab)

Another neat thing to have would be if there was a Reload without cache option (although this should probably be a separate ticket)

Again, thanks heaps for your prompt responses

emvaized commented

Unfortunately, iframes support could not be added as configuration toggle – it's either enabled for everyone or not, because such behavior should be explicitly stated in the extension manifest.

Reload without cache option

This one is possible.

robertwhitlock3 commented

Pardon my ignorance - I'm not a JavaScript Dev - but if the iFrame support was implemented something along the lines of https://stackoverflow.com/a/11326942, then the manifest entry could be implemented for all, then the set up of the listeners/message passing could be made conditional to the configuration option.

(sorry for the pestering - a number of work-internal sites that I'm forced to use on a daily basis must be using iFrames and I really want to continue using this extension)

emvaized commented

The solution you shared may partially solve 1, but I think it could be solved in a more compact and lightweight way with more active usage of the chrome tabs api. Either way, it will require going through all the available actions, testing their behavior in iframes and rewriting some – which I could not promise when I'll have a time for.

robertwhitlock3 commented

No worries. Thanks for your time considering this. Should I close the ticket?

emvaized commented

I think would be better to keep it open as a reminder to think about it later

emvaized commented

I gave iframes support a second thought, and perhaps I'd say "no" to this feature for now. Enabling gestures inside the iframe causes clip-off issue mentioned above, as well as wrong positioning when menu is shown in corner, and unintuitive behavior when user is not aware menu was opened in an iframe context.

And the second approach (catch the mouse event in iframe, and pass it to the main window to process) will also lead to unintended behavior, as sometimes user will want action to be applied to the iframe, and not the main page (for example, "scroll up/down"). And also it will require too much of work and testing, considering quite rare occurrences where it can actually be useful, as most websites do not actually use in-page iframes for displaying content.

So I think I'll close this for now, but will be happy to reopen in case there will be new reasons to reconsider