[Ubuntu 16.04] Missing mouse pointer from Firefox window share

Assigned to



2 years ago
11 months ago


(Reporter: bogdan_maris, Assigned: jesup)




Firefox Tracking Flags

(firefox48 unaffected, firefox49 wontfix, firefox50 affected, firefox51 affected)



(2 attachments)

Created attachment 8787110 [details]
Screencast showing the issue

[Affected versions]:
- Firefox 49 beta 8
- Latest Developer Edition 50.0a2
- Latest Nightly 51.0a1

[Affected platforms]:
- Ubuntu 16.04 x32 and x64

[Steps to reproduce]:
1. Open Firefox
2. Open https://mozilla.github.io/webrtc-landing/gum_test.html in a new tab
3. Click Window
4. Select the window to share
5. Move mouse in the shared window

[Expected result]:
- Mouse pointer is displayed

[Actual result]:
- Mouse pointer is invisible

[Regression range]:
- This is a recent regression. Here is the mozregression output:

Last good revision: c23ff1725f56734958eb2978040ab36f278a6063
First bad revision: 317aecd284b8a55b335a016a1a5bed3278893c9f

I think that this is the bug that caused this:
51c543f66795	Randell Jesup — Bug 1042631: Fix Linux mouse position when sharing a window in WebRTC screensharing r=ng
Flags: needinfo?(rjesup)
I can reproduce this, and I also get interesting positions of the gUM permission prompt.
Rank: 13
Priority: -- → P1
Assignee: nobody → rjesup

Comment 2

2 years ago
Ok, with 16.04 I see it as well.  GDB tells me that child_window from XQueryPointer is never coming back as non-0 (aka None), and thus we're being told the pointer isn't in the window.
Flags: needinfo?(rjesup)

Comment 3

2 years ago
Unmarking regression since (for Ubuntu 16) this simply replaced one bug (wrong position of the cursor) with a different bug (no cursor).

WONTFIX for 49 since it's too late and the fix isn't simple.  Also this highlights that the fix for Bug 1042631 is incomplete, in that windows that are composited (like an Emacs window with the inner frame aand outer menu-subtitle and borders) doesn't show the cursor in the outer area.

Better would be to change how the compositing is done.
status-firefox49: affected → wontfix
Keywords: regression

Comment 4

2 years ago
Created attachment 8787671 [details] [diff] [review]
Use topmost Window when selecting a window for sharing

Using the topmost window associated with the picked window works much better - it's consistent (emacs windows for example would share the menubar and contents, while calculator and other 'interior-less' windows would share the decorations).  It fixes the cursor positioning better than the earlier fix, since the cursor compositing now works over the menu bars.  It does expose *all* the WM decorations unfortunately, including dropshadows, but consistently removing the ones we don't want is Not Easy given the wide range of WMs, and we do get the window titles (which are also a decoration).  A very simple fix; almost all the lines of this are moving the GetTopLevelWindow() function to a shared file.   NOTE: this patch assumes we backout bug 1042631 and apply this instead.
Attachment #8787671 - Flags: review?(karlt)
Comment on attachment 8787671 [details] [diff] [review]
Use topmost Window when selecting a window for sharing

As alluded in comment 2, the problem is the interpretation of child_return
from XQueryPointer.

Trying to draw the decorations is difficult because what works with one window
manager will not work with another.

-// WindowCapturer returns window IDs of X11 windows with WM_STATE attribute.
-// These windows may not be immediate children of the root window, because
-// window managers may re-parent them to add decorations. However,
-// XQueryPointer() expects to be passed children of the root. This function
-// searches up the list of the windows to find the root child that corresponds
-// to |window|.

XQueryPointer() doesn't expect to be passed children of the root window, but
isn't quite the API that is required for all the desired information in a
single call.

MouseCursorMonitorX11::Capture() expects the window passed to XQueryPointer to
be a parent of only the captured window.

This patch may help with window managers that provide a single parent window
for the decorations, but some window managers won't do this [1].  Even for
window managers that do provide a consistent parent, whether the cursor shows
over decorations depends on the window manager having a child window covering

Whether the WM is reparenting or not, if there is a virtual root present [2],
then GetTopLevelWindow()/SelectWindow() would end up selecting the entire
virtual root, not just the decorations.

Instead, calling XQueryPointer twice, once with the selected window and once
with the root window would provide enough information to know the cursor
position relative to the selected window, whether the pointer is over a
descendant of the selected window, and whether the pointer is over the
selected window.

MouseCursorMonitor::CreateForWindow() and WindowCapturerLinux::SelectWindow()
can then each operate on the window indicated in their parameter.
The more complicated task of displaying the window decorations, if desired, is
really separate from this bug.  If displaying the title is necessary, then
perhaps better UI could be provided than drawing decorations.

I wonder how necessary it is to hide the cursor when another window is
occluding the selected window.  If not critical, then maybe
CursorState::INSIDE can be passed when unknown, and only one XQueryPointer
call would be required.

EnterWindowMask/LeaveWindowMask events may provide a more efficient accurate
solution to minimize XQueryPointer round trips.  I guess the change in
behavior wrt pointer grabs would be fine, but I'm not certain.  Xlibint.h or
libxcb are other possible ways to perform two operations in one round trip.
However, such optimizations need not be in the first correct implementation.

[1] https://en.wikipedia.org/wiki/Re-parenting_window_manager
[2] https://specifications.freedesktop.org/wm-spec/wm-spec-1.5.html#idm140200477402304
Attachment #8787671 - Flags: review?(karlt)

Comment 6

2 years ago
This problem also occurs on Macos Sierra with latest Nightly.
Mass change P1->P2 to align with new Mozilla triage process
Priority: P1 → P2
You need to log in before you can comment on or make changes to this bug.