[Webkit-unassigned] [Bug 186676] [GTK] visibilitychange event not fired when window moved to a separate workspace
bugzilla-daemon at webkit.org
bugzilla-daemon at webkit.org
Sun Jun 17 10:55:44 PDT 2018
Michael Catanzaro <mcatanzaro at igalia.com> changed:
What |Removed |Added
--- Comment #3 from Michael Catanzaro <mcatanzaro at igalia.com> ---
I think Microsoft Edge and Internet Explorer are not Wayland clients. :)
I compared Epiphany's behavior to Firefox's and found Epiphany's is identical. When opening your test in firefox-wayland, I see visibility notifications only if I switch to another tab within Firefox itself. Same with Epiphany. Firefox does not send any visibility change events when it is switched to another workspace.
I also tested the normal firefox binary, which is not directly relevant because it is an obsolete XWayland client. It had almost the same behavior. The difference was that the normal Firefox was additionally able to send visibility notifications when maximized and minimized. Neither firefox-wayland nor Epiphany were able to do this. I think we should be able to detect minimization ("iconification") by watching GtkWidget::window-state-event, but that's not what you requested here.
I asked the GTK+ developers for a way to detect if the window is visible, and sadly they say it is not possible. We would need to add a Wayland protocol to indicate visibility to clients (probably to xdg-shell), and they did not seem interested in adding that functionality to mutter/weston or to GTK+. So to progress this would need changes there. Here's the full conversation if you're interested:
mcatanzaro Hey, is there a way in GTK+ Wayland to detect whether a focused window is currently visible? We need to know if it's e.g. focused but on a non-visible workspace, for https://bugs.webkit.org/show_bug.cgi?id=186676
Company mcatanzaro: apart from mapped/unmapped I don't think there's a way to track it inside GTK
mcatanzaro Company: gtk_widget_get_mapped()?
and WMs don't usually unmap windows anymore
mcatanzaro Yeah that's the problem, so the window will be mapped even if it's offscreen, right?
ebassi mcatanzaro: Yes
It's something that happens on X11 as well
mcatanzaro So this is CANTFIX
ebassi Since the advent of compositors
Company I'm not aware of any API to track visibility
mcatanzaro But on X11 at least you can query to see which workspace you are on
ebassi mcatanzaro: If the WM is using workspaces
mcatanzaro So I wouldn't be surprised if Firefox or Chromium had some hack to make this work
ebassi Not if it's using viewports, for instance
mcatanzaro Viewports aren't real anymore :)
I don't like that API
ebassi mcatanzaro: Isn't Compiz still using viewports?
Company I don't need ad popups to stop their countown when i'm not looking at them...
mcatanzaro It's probably important for battery life, though
ebassi AFAIR, Chrome disables high performance counters on focus out; so the ads keep running, but they won't wake up your system just as often
mcatanzaro We want to throttle timers when pages are not visible
ebassi focus out/tab out
Company that's focus though, not visibility
ebassi I've definitely seen timers in JS not working when switching tabs
mcatanzaro Using focus also fails because we have one focused window per workspace
So it can be focused but not visible
Times like this make me wonder how software is supposed to work. In general.
Company mcatanzaro: in general, my approach to visibility has been that it's impossible to do from inside the app and needs explicit compositor support
mcatanzaro: and generally compositors have not been very interested in tracking that - mostly because apps didn't really care about it
mcatanzaro I wonder how Firefox and Chromium handle onvisibility then... in Wayland, at least
Company X has VisibilityNotify events, but I removed support for those, because they don't work
ebassi mcatanzaro: Key focus/pointer crossing is how the compositors have been able to tell the app "you have the user's attention"
mcatanzaro I guess Chromium is still an XWayland client, so only Firefox in experimental Wayland mode is a relevant comparison
Company mcatanzaro: theres also (at least) 2 meanings of what visibility means
ebassi But we live in a world where you can leave your web browser in the background playing music, these days
Company mcatanzaro: because if an app is on another workspace but you open the shell overlay, is that app now visible?
mcatanzaro: or if it's overlayed by a semi-transparent terminal, is it still visible?
mcatanzaro I'd say "yes" because otherwise the app could black out its window trusting that it is not visible, and it would be a compositor bug to show that
Visible should mean visible
I guess that proves that visibility is for sure different from focus
Company mcatanzaro: so whenever i press alt-tab you emit a visibility event - and another one when i release the tab key?
mcatanzaro I would say yes
Maybe that's dumb, dunno
Company mcatanzaro: so if i have an opaque app using an RGBA visual on top of your app, is your app still visible?
ebassi If you black out your contents, and then Super+tab around, the app may need to redraw, which may take a while
So it's still not going to look super nice
Company mcatanzaro: but if I make the app only partially opaque and your app still shines through, it's visible?
Company mcatanzaro: do i need to track that per pixel? is 1 transparent pixel shining through enough?
mcatanzaro Company: I would say yes, that is visible
Again, might be dumb...
Company that means my compositor has to download each frame from my app, inspect every pixel and if one of them is not opaque, it sends an event to your app?
that seems a tiny bit slow?
luckily, the relevant pixel is often the top left one, because we all use rounded corners for our decorations and they shine through!
what i'm trying to say is: this concept makes no sense in practice
Company it sounds like a really useful thing in theory, but with our focus on translucency and rounded corners and shadows and whatnot it's pretty much impossible to define or implement meaningfully and fast
You are receiving this mail because:
You are the assignee for the bug.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the webkit-unassigned