You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
{{ message }}
This repository has been archived by the owner on May 5, 2019. It is now read-only.
The current behavior is identical to chromium, which prevents focusing a second window while an alert is open on the first. I seem to remember seeing articles about some websites relying on interaction being blocked in order to function correctly.
It seems possible, however, to implement custom UI for these alerts which may prevent blocking other windows/tabs. The obvious approach is to completely expose the WebKit API to Lua, which allows maximum flexibility, but also adds complexity; likely a lot of code would now have to check whether an alert is active, there's the possibility of multiple alerts on separate tabs, changes to the modes/binds infrastructure, etc. etc.
In general I'm not against accepting some risk of website breakage in exchange for increased user flexibility, especially when such websites are few and far between. I'll look for any articles on the design decisions behind interaction blocking and then see what I can do.
Upon closer inspection, it appears the relevant WebKitGTK signal script-dialog is designed to be connected to a handler that blocks the main loop while a GTK dialog is shown. This basically makes it useless, and prevents any modification of the window blocking behavior.
I'll leave this issue open, as it's possible that improved APIs will be available in the future.
Sign up for freeto subscribe to this conversation on GitHub.
Already have an account?
Sign in.
What I do:
What I expect:
only the tab where alert is invoked is blocked
The text was updated successfully, but these errors were encountered: