[Webkit-unassigned] [Bug 186676] [GTK] visibilitychange event not fired when window moved to a separate workspace

[bugzilla-daemon at webkit.org]

https://bugs.webkit.org/show_bug.cgi?id=186676

Michael Catanzaro <mcatanzaro at igalia.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |WONTFIX

--- 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()?

Company yeah
and WMs don't usually unmap windows anymore
i think

mcatanzaro      Yeah that's the problem, so the window will be mapped even if it's offscreen, right?

Company yes

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 :)

Company also
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

Company: Yeah

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?

mcatanzaro      No?

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?

mcatanzaro      Yes

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...
URL: <http://lists.webkit.org/pipermail/webkit-unassigned/attachments/20180617/dbabda81/attachment.html>