xpra icon
Bug tracker and wiki

Opened 10 months ago

Last modified 2 months ago

#1658 assigned defect

mouse events in black border around desktop area

Reported by: mviereck Owned by: Antoine Martin
Priority: minor Milestone: 2.4
Component: client Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

xpra v2.2-r17160 on debian 9

If running xpra --start-desktop and maximizing the client window, there can be a black area around the shown desktop if the vfb X server does not provide a matching resolution.

Mouse events (moving and clicks) in the black area should not do anything, but they happen to the outer border of the desktop.

Example: mouse click in black area above clock in xfce4-panel shows calendar, but this should only happen if I click directly on the clock.
example of black border around the window contents

Mouse movements in black area above the panel causes highlighting of nearest panel objects.

Not really a problem so far, just different from what I would expect.

Attachments (1)

black-border.jpg (29.9 KB) - added by Antoine Martin 7 months ago.
example of black border around the window contents

Download all attachments as: .zip

Change History (9)

comment:1 Changed 10 months ago by Antoine Martin

Milestone: 2.23.0
Status: newassigned

Originally reported in #1656, see ticket:1656#comment:24.

If we swallow pointer motion events, there are some potential problems with seamless mode when the window size does not match its contents exactly: the virtual pointer could linger on the edge of the server side window - which could trigger unwanted behaviour.

Changed 7 months ago by Antoine Martin

Attachment: black-border.jpg added

example of black border around the window contents

comment:2 Changed 7 months ago by Antoine Martin

Description: modified (diff)

there can be a black area around the shown desktop if the vfb X server does not provide a matching resolution.

This is less of a problem nowadays since you can:

  • use Xvfb and have perfect match for any resolutions
  • Xdummy now has a large set of pre-defined resolutions which should match all possible configurations with a maximum gap of 128 pixels

(converted link to an attachment so it doesn't bitrot)

comment:3 Changed 6 months ago by mviereck

This happens rather with Xwayland than with Xvfb or Xdummy as it unfortunately does not support resolution changes with xrandr.

In seamless mode for single applications I do not expect an issue as they are always scaled up to the client screen resolution. In that case I am not able to move the mouse outside of the virtual desktop.

comment:4 Changed 6 months ago by Antoine Martin

This happens rather with Xwayland than with Xvfb or Xdummy as it unfortunately does not support resolution changes with xrandr.

Then this is an unsupported configuration, we rely on randr to make things match. Use Xvfb instead.

comment:5 Changed 6 months ago by mviereck

Use Xvfb instead.

For most things I use Xvfb or Xdummy. Xwayland has the advantage of supporting hardware acceleration, but the disadvantage of bad xrandr support.

Aside from this minor issue of mouse events at the edge in desktop mode, xpra works quite well with Xwayland. Also, xpra clients sets the window size right, the issue only appears if I maximize the window.

So far, it is fine for me, xpra handles Xwayland quite well.

comment:6 Changed 3 months ago by Antoine Martin

Milestone: 3.02.4

comment:7 Changed 2 months ago by Antoine Martin

Testing as per ticket:1656#comment:12

  • I can only reproduce this bug by maximizing the window, so r19613 detects wayland / that randr doesn't work and the window is now made non-resizable, non-maximizable
  • the non-opengl backends have problems rendering correctly with the offsets, new ticket: #1874
  • r19615 fixes the pointer events issue: shadow and desktop servers discard events that land outside the vfb rather than clipping them (seamless servers are unchanged: the events may be outside the window but they will still land on the vfb so we still want them) - easier to test by patching check_randr_sizes to return True (just like #1874)

Still TODO:

  • check win32 and macos shadow servers with multi-window mode (#1805) and check for regressions
  • maybe handle the transition from discarded to not-discarded and back by sending cursor updates so that the client doesn't show the cursor that would apply if the pointer was still in the active region of the window? (ie: the edge of the window may have a resize handle, which is no longer relevant when hovering over the padding area since both motion and button events will be ignored there)

comment:8 Changed 2 months ago by Antoine Martin

The cursor handling is "fixed" in r19621, though it does break the neat dependency separation from #1838.

Only one item left: re-test all the desktop and shadow servers with multi-window mode by hand. (#1805) Maybe use fullscreen to trigger more easily?

Last edited 2 months ago by Antoine Martin (previous) (diff)
Note: See TracTickets for help on using tickets.