1. 22 Oct, 2020 3 commits
  2. 19 Oct, 2020 1 commit
    • Olivier Fourdan's avatar
      window: Do not go past size hints on resize · 03c69ed8
      Olivier Fourdan authored
      On interactive resize, mutter calculates the difference in size based on
      the pointer location and relies on window constraints to ensure the
      minimum size is honored.
      Wayland however does asynchronous window configuration, meaning that not
      checking for size hints early enough may lead to the window moving as
      the locations was initially computed on a size which will be invalidate
      by the client eventually.
      Make sure to respect the client size hint on update_resize() so that we
      don't end up with a window moving unexpectedly when the client
      eventually acked the configuration.
  3. 14 Oct, 2020 3 commits
  4. 08 Oct, 2020 1 commit
  5. 06 Oct, 2020 1 commit
  6. 29 Aug, 2020 1 commit
  7. 04 Aug, 2020 1 commit
    • Sergio Costas's avatar
      wayland: Add API to launch trusted clients · f894f5cc
      Sergio Costas authored
      Allowing code from inside mutter to create a child process and
      delegate on it some of its tasks is something very useful. This can
      be done easily with the g_subprocess and g_subprocess_launcher classes
      already available in GLib and GObject.
      Unfortunately, although the child process can be a graphical program,
      currently it is not possible for the inner code to identify the
      windows created by the child in a secure manner (this is: being able
      to ensure that a malicious program won't be able to trick the inner
      code into thinking it is a child process launched by it).
      Under X11 this is not a problem because any program has full control
      over their windows, but under Wayland it is a different story: a
      program can't neither force their window to be kept at the top (like a
      docker program does) or at the bottom (like a program for desktop icons
      does), nor hide it from the list of windows. This means that it is not
      possible for a "classic", non-priviledged program, to fulfill these
      tasks, and it can be done only from code inside mutter (like a
      gnome-shell extension).
      This is a non desirable situation, because an extension runs in the
      same main loop than the whole desktop itself, which means that a
      complex extension can need to do too much work inside the main loop,
      and freeze the whole desktop for too much time. Also, it is important
      to note that javascript doesn't have access to fork(), or threads,
      which means that, at most, all the parallel computing that can do is
      those available in the _async calls in GLib/GObject.
      Also, having to create an extension for any priviledged graphical
      element is an stopper for a lot of programmers who already know
      GTK+ but doesn't know Clutter.
      This patch wants to offer a solution to this problem, by offering a
      new class that allows to launch a trusted child process from inside
      mutter, and make it to use an specific UNIX socket to communicate
      with the compositor. It also allows to check whether an specific
      MetaWindow was created by one of this trusted child processes or not.
      This allows to create extensions that launch a child process, and
      when that process creates a window, the extension can confirm in a
      secure way that the window really belongs to that process
      launched by it, so it can give to that window "superpowers" like
      being kept at the bottom of the desktop, not being listed in the
      list of windows or shown in the Activities panel... Also, in future
      versions, it could easily implement protocol extensions that only
      could be used by these trusted child processes.
      Several examples of the usefulness of this are that, with it, it
      is possible to write programs that implements:
      - desktop icons
      - a dock
      - a top or bottom bar
      all in a secure manner, avoiding insecure programs to do the same.
      In fact, even if the same code is launched manually, it won't have
      those privileges, only the specific process launched from inside
      Since this is only needed under Wayland, it won't work under X11.
      Fixes #741
  8. 28 Jul, 2020 1 commit
  9. 16 Jun, 2020 1 commit
  10. 21 May, 2020 6 commits
    • verdre's avatar
      window: Add a note about the trustworthiness of the client PID · b97a6e62
      verdre authored
      Since PIDs are inherently insecure because they are reused after a
      certain amount of processes was started, it's possible the client PID
      was spoofed by the client.
      So make sure users of the meta_window_get_pid() API are aware of those
      issues and add a note to the documentation that the PID can not be
      totally trusted.
    • verdre's avatar
      window: Cache the client PID · 4fac1a48
      verdre authored
      Since the PID of a window can't change as long as the window exists, we
      can safely cache it after we got a valid PID once, so do that by adding
      a new `window->client_pid` private property.
    • verdre's avatar
      window: Return pid_t in meta_window_get_pid() · 70ba844c
      verdre authored
      Just as with the last commit, pid_t is compatible with all platforms and
      we should use that everywhere, so also make meta_window_get_pid() return
      a pid_t.
    • verdre's avatar
      window: Use pid_t for get_client_pid() vfunc · bc0b9f76
      verdre authored
      It makes sense to use pid_t when getting the PID since that will work on
      all platforms and architectures.
    • verdre's avatar
      window: Remove support for _NET_WM_PID · c971d6ea
      verdre authored
      We have the client pid API that works on both Wayland and X11 nowadays,
      so the _NET_WM_PID property is no longer needed, remove it.
    • verdre's avatar
      window: Use client PID for meta_window_get_pid() · dac09a8e
      verdre authored
      The shell uses the PID of windows to map them to apps or to find out
      which window/app triggered a dialog. It currently fails to do that in
      some situations on Wayland, because meta_window_get_pid() only returns a
      valid PID for x11 clients.
      So use the client PID instead of the X11-exclusive _NET_WM_PID property
      to find out the PID of the process that started the window. We can do
      that by simply renaming the already existing
      meta_window_get_client_pid() API to meta_window_get_pid() and moving
      the old API providing the _NET_WM_PID to meta_window_get_netwm_pid().
  11. 07 May, 2020 2 commits
    • Jonas Ådahl's avatar
      window: Set fall-back tile monitor if not set · 033f0d11
      Jonas Ådahl authored
      When tiling, we want to set the tile monitor. To not have to do this
      from the call site, make meta_window_tile() fall back to the current
      monitor if nothing set it prior to the call.
      This will make it more convenient for test cases to test tiling
    • Jonas Ådahl's avatar
      window: Add meta_window_untile() · 668eb318
      Jonas Ådahl authored
      It does the same as the untile keyboard shortcut does, i.e. handles
      going back to saved maximized state. It's split out to be able to be
      tested by the stacking tests.
  12. 16 Apr, 2020 1 commit
  13. 07 Apr, 2020 1 commit
    • Jonas Ådahl's avatar
      window: Check aliveness a bit less aggressively · 8df3b21a
      Jonas Ådahl authored
      Currently we check whether a window is alive everytime it's focused.
      This means that an application that doesn't respond to the check-alive
      event during startup always showing the "application froze" dialog,
      without the user ever trying to interact with it.
      An example where this tends to to happen is with games, and for this
      particular scenario, it's purely an annoyance, as I never tried to
      interact with the game window in the first place, so I don't care that
      it's not responding - it's loading.
      To avoid these unnecessary particular "app-is-frozen" popups, remove the
      alive check from the focus function, and instead move it back to the
      "meta_window_activate_full()" call. To also trigger it slightly more
      often, also add it to the path that triggers the window focus when a
      user actively clicks on the window.
      This means that we currently check whether a window is alive on:
        * Any time the window is activated. This means e.g. alt-tab or
          selecting the window in the overview.
        * The user clicks on the window.
      Note that the second only works for an already focused window on
      Wayland, as on X11, we don't refocus it. This particular case isn't
      changed with this commit, as we didn't call meta_window_focus() to begin
      with here.
  14. 26 Mar, 2020 1 commit
    • Jonas Ådahl's avatar
      cogl: Install cogl-trace.h and include from cogl.h · 238e41d4
      Jonas Ådahl authored
      This is so that cogl-trace.h can start using things from cogl-macros.h,
      and so that it doesn't leak cogl-config.h into the world, while exposing
      it to e.g. gnome-shell so that it can make use of it as well. There is
      no practical reason why we shouldn't just include cogl-trace.h via
      cogl.h as we do with everything else.
  15. 24 Mar, 2020 1 commit
    • Florian Müllner's avatar
      window: Really propagate effective on-all-workspaces setting to transients · d4c070da
      Florian Müllner authored
      Commit cda95790 fixed a corner case when setting the initial workspace
      state of transient windows, but it still missed a case:
      should_be_on_all_workspaces() returns whether the window should be on all
      workspaces according to its properties/placement, but it doesn't take
      transient relations into account.
      That means in case of nested transients, we can still fail the assert:
       1. on-all-workspaces toplevel
       2. should_be_on_all_workspaces() is TRUE for the first transient's parent,
          as the window from (1) has on_all_workspaces_requested == TRUE
       3. should_be_on_all_workspaces() is FALSE for the second transient's
          parent, as the window from (2) is only on-all-workspace because
          of its parent
      We can fix this by either using the state from the root ancestor
      instead of the direct transient parent, or by using the parent's
      The latter is simpler, so go with that.
  16. 29 Feb, 2020 4 commits
    • Jonas Ådahl's avatar
      window: Implement asynchronous popup moving · d08a8de2
      Jonas Ådahl authored
      This commits adds support on the MetaWindow and constraints engine side
      for asynchronously repositioning a window with a placement rule, either
      due to environmental changes (e.g. parent moved) or explicitly done so
      via `meta_window_update_placement_rule()`.
      This is so far unused, as placement rules where this functionality is
      triggered are not yet constructed by the xdg-shell implementation, and
      no users of `meta_window_update_placement_rule()` exists yet.
      To summarize, it works by making it possible to produce placement rules
      with the parent rectangle a window should be placed against, while
      creating a pending configuration that is not applied until acknowledged
      by the client using the xdg-shell configure/ack_configure mechanisms.
      An "temporary" constrain result is added to deal with situations
      where the client window *must* move immediately even though it has not yet
      acknowledged a new configuration that was sent. This happens for example
      when the parent window is moved, causing the popup window to change its
      relative position e.g. because it ended up partially off-screen. In this
      situation, the temporary position corresponds to the result of the
      movement of the parent, while the pending (asynchronously configured)
      position is the relative one given the new constraining result.
    • Jonas Ådahl's avatar
      Add MetaGravity and replace X11 equivalent with it · 0dac91cf
      Jonas Ådahl authored
      MetaGravity is an enum, where the values match the X11 macros used for
      gravity, with the exception that `ForgetGravity` was renamed
      `META_GRAVITY_NONE` to have less of a obscure name.
      The motivation for this is to rely less on libX11 data types and macros
      in generic code.
    • Jonas Ådahl's avatar
      constraints: Pass constrained relative coordinates to window impl · ff381d1d
      Jonas Ådahl authored
      A placement rule placed window positions itself relative to its parent,
      thus converting between relative coordinates to absolute coordinates,
      then back to relative coordinates implies unwanted restrictions for
      example when the absolute coordinate should not be calculated againts
      the current parent window position.
      Deal with this by keeping track of the relative position all the way
      from the constraining engine to the move-resize window implementation.
    • Jonas Ådahl's avatar
      window: Put placement related fields in a anynomous struct · 05e9d6ab
      Jonas Ådahl authored
      To organize things a bit better, put the fields related to the placement
      rule state in its own anonymous struct inside MetaWindow. While at it,
      rename the somewhat oddly named variable that in practice means the
      current relative window position.
  17. 19 Feb, 2020 2 commits
    • Jonas Ådahl's avatar
      wayland: Move MetaWindow ownership to window owning roles · 44ae3859
      Jonas Ådahl authored
      There are two surface roles owning a MetaWindow: MetaWaylandShellSurface
      (basis of MetaWaylandXdgToplevel, MetaWaylandXdgPopup,
      MetaWaylandWlShellSurface, etc), and MetaXwaylandSurface.
      With these two role types, the MetaWindow has two different types of
      life times. With MetaWaylandShellSurface, the window is owned and
      managed by the role itself, while with MetaXwaylandSurface, the
      MetaWindow is tied to the X11 window, while the Wayland surface and its
      role plays more the role of the backing rendering surface.
      Before, for historical reasons, MetaWindow was part of
      MetaWaylandSurface, even though just some roles used it, and before
      'wayland: Untie MetaWindowXwayland lifetime from the wl_surface' had
      equivalent life times as well. But since that commit, the management
      changed. To not have the same fied in MetaWaylandSurface being managed
      in such drastically different ways, rearrange it so that the roles that
      has a MetaWindow themself manages it in the way it is meant to; meaning
      MetaWaylandShellSurface practically owns it, while with Xwayland, the
      existance of a MetaWindow is tracked via X11.
    • verdre's avatar
      window: Check window responsiveness on every window focus · d053ccfb
      verdre authored
      Increase the number of checks whether a window is still responsive and
      ping windows on every call to `meta_window_focus()` instead of
      `meta_window_activate_full()`. This ensures the window is also pinged in
      case normal interaction like clicks on the window happen and a close
      dialog will eventually get shown.
      Related #395
  18. 04 Feb, 2020 1 commit
    • Florian Müllner's avatar
      window: Ignore requests to be placed on non-existent workspaces · aa0aa89a
      Florian Müllner authored
      When an X11 window requests an initial workspace, we currently trust
      it that the workspace actually exists. However dynamic workspaces
      make this easy to get wrong for applications: They make it likely
      for the number of workspaces to change between application starts,
      and if the app blindly applies its saved state on startup, it will
      trigger an assertion.
      Make sure that we pass valid parameters to set_workspace_state(),
      and simply let the workspace assignment fall through to the default
      handling otherwise.
  19. 30 Jan, 2020 3 commits
  20. 09 Dec, 2019 3 commits
  21. 29 Nov, 2019 2 commits
    • Florian Müllner's avatar
      stack: Delegate layer calculation to a window vfunc · c843102e
      Florian Müllner authored
      While most of the code to compute a window's layer isn't explicitly
      windowing backend specific, it is in practice: On wayland there are
      no DESKTOP windows(*), docks(*) or groups.
      Reflect that by introducing a calculate_layer() vfunc that computes
      (and sets) a window's layer.
      (*) they shall burn in hell, amen!
    • Florian Müllner's avatar
      window: Add get_default_layer() helper · b753213f
      Florian Müllner authored
      Most of the layer computation that the stack does actually depends
      on the windowing backend, so we will move it to a vfunc.
      However before we do that, split out the bit that will be shared.