Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Does not work with extension popup inside Firefox #3

Closed
snippins opened this issue Apr 16, 2023 · 6 comments
Closed

Does not work with extension popup inside Firefox #3

snippins opened this issue Apr 16, 2023 · 6 comments

Comments

@snippins
Copy link

I can invoke extension buttons using vimium-everywhere to open their corresponding popup windows, but try invoke vimium-everywhere again would make the Firefox window lose focus and close the windows.

A possible x11 solution is to create the overlay window with override-redirect flag, so that window managers won't manage the window, thus there is no focus changes and the popup stays open. However, I don't really know how to do that using the ahk scripting language.
https://tronche.com/gui/x/xlib/window/attributes/override-redirect.html

@phil294
Copy link
Owner

phil294 commented Apr 17, 2023

Hello,

I have noticed this problem too, for example you can't toggle uBlock for a site by keyboard and I think I have found the errors:

The Gui is always created with Gtk. Gtk seems to set override-redirect when you pass the window option accept_focus, can_focus or type_hint: tooltip. It must be either of those because that's what Tooltip windows have and they don't take away focus. (edit: no, it's actually the window type set to popup at creation time) As for AHK, this would be Gui, +E0x8000000 as per WS_EX_NOACTIVATE = 0x08000000L extended-window-styles / Gui, Options "Unnamed ExStyle". I have to add this to AHK_X11 first where I'm currently working on other stuff, so it will take a few days to weeks.

Apart from that, currently even hotkey presses alone kill popup focus already such as f::Return because we send an up event on hotkey press because of jordansissel/xdotool#406 (comment), so I guess this hack needs to be done only when the first command is a Send or SendRaw...

tl;dr thanks for brining this up

phil294 added a commit to phil294/AHK_X11 that referenced this issue Jul 2, 2023
but only `+0x80000000` and `+E0x8000000` for now, as they are needed for phil294/vimium-everywhere#3. Other styles are probably very low priority or just don't apply on Linux at all.
phil294 added a commit to phil294/AHK_X11 that referenced this issue Jul 2, 2023
…ol bug workaround) *only if* the first command is a `Send` or `SendRaw`

In other words, if the hotkey isn't used for sending text (which we assume it isn't if the first command is something else, out of simplicity), it's okay for the key to be eaten up a bit. Doing the Send workaround does send something to X11 after all which could be undesired and should be avoided: See:
Needed for phil294/vimium-everywhere#3
@phil294
Copy link
Owner

phil294 commented Jul 2, 2023

FYI I have fixed both of these problems now (locally), finally. However, a third one appeard (yay!): The active window always loses its focus for the duration of any "grabbed" key being held down: https://stackoverflow.com/q/15270420. This is a global problem and has nothing to do with ahk_x11 as can be seen in the upvote ratio of the question. I will try out this workaround https://stackoverflow.com/questions/15270420/why-xgrabkey-generates-extra-focus-out-and-focus-in-events/69216578#69216578 another time, but it might introduce various new bugs so I need to test it out properly first. Thanks for your patience.

There is also the option of using non-grabbing hotkeys (in ahk notation: ~ prefix) so that the original function of the key is not caught/trapped and still recognized by the window. This is rather annoying though, e.g. if you have installed normal Vimium too then an ALTF keypress would trigger both vimiums. You could use another unused hotkey like F8 but that's not quite ergonomic :s

... and there's a fourth bug, running vimium-everywhere on a popup window crashes the entire program, but this will hopefully be a quick fix

phil294 added a commit to phil294/AHK_X11 that referenced this issue Jul 5, 2023
… there instead of doing so on the root window.

While the latter was easier, we avoid losing focus from the active window while a grabbed key is pressed down. This helps avoiding various popups and menus from auto-closing on hotkey press.

https://stackoverflow.com/a/69216578/3779853
ref phil294/vimium-everywhere#3
phil294 added a commit to phil294/AHK_X11 that referenced this issue Jul 5, 2023
phil294 added a commit to phil294/AHK_X11 that referenced this issue Jul 5, 2023
This is essentially the same as 53fa4c7, but for `XGrabKeyboard`, not just `XGrabButton`. See that commit for details

ref phil294/vimium-everywhere#3
@phil294 phil294 closed this as completed in c2e22ad Jul 5, 2023
@phil294 phil294 reopened this Jul 5, 2023
@phil294
Copy link
Owner

phil294 commented Jul 6, 2023

Finally fixed! Would be great if you could test it out. https://github.com/phil294/vimium-everywhere/releases

@phil294 phil294 closed this as completed Jul 6, 2023
@rpbritton
Copy link

Funnily enough, I posted that solution to stack overflow when writing a project for the same f shortcut functionality. Cool to see it being used for the same thing!

@phil294
Copy link
Owner

phil294 commented Jul 8, 2023

@rpbritton cool, is that project open source? can you link it or the SO post?

@phil294
Copy link
Owner

phil294 commented Jul 8, 2023

NVM, I found it: https://github.com/rpbritton/goodnight-mouse

I'm really impressed!! I had searched for ages for something like this before starting my project. I will test yours out a bit, figure out the differences (including performance) and add it to the README.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants