Open Bug 1343281 Opened 7 years ago Updated 2 years ago

Mouse capturing does not work with org.gnome.desktop.wm.preferences focus-mode set to 'sloppy'

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P3)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
All
Linux
Type:
defect

Tracking

()

People

(Reporter: julienw, Unassigned)

References

Details

(Keywords: regression)

Attachments

(4 files)

mouseup-out-browser.html
990 bytes, text/html
Details
screen recording of working mouse capturing on debian
665.12 KB, video/mp4
Details
Screen recording of the issue
1.48 MB, video/ogg
Details
testcase using setCapture when present
1006 bytes, text/html
Details 
STR:
1. Open the attachment.
2. Take care that your browser window isn't fullscreen.
3. Start a mousedown event on the green square.
4. Keep the left button pressed while moving the mouse out of the browser window.
5. release the left button.
6. bring back the mouse inside the green square

=> notice we get mousemove events.

I understand what's happening: we don't get the mouseup event because we're out of the browser window.

Yet with Chrome we get it, but according to my tests, only if we attach the event listeners to "document".

In Firefox this kind of works if we use element.setCapture inside mousedown. I say "kind of" because it still doesn't if Firefox loses the focus (for example on Linux with "focus follow mouse").

I think we need a solution here. Moreover we'd need it in the Devtools HTML rewrite.
This is similar to bug 1257813 and bug 1187591 I think. I'll ask Olli about what he thinks we should do here.
Priority: -- → P2
Any update on this ? :)
FWIW we can see the same issue on websites like jsbin.com, eg http://jsbin.com/bomuno/edit?html,output. Try to resize the panels, keep your mouse button down while you move the mouse cursor out of the browser window, then release the button and bring the mouse cursor back in the browser window. You'll see that the webpage still "thinks" the resize operation is happening, and it looks broken.
This doesn't happen on Chrome.

I think that at first we should get the same behavior as chrome, as I expect a lot of pages rely on this undocumented behavior.
Is this a regression?
Keywords: regressionwindow-wanted
OS: Unspecified → Linux
Hardware: Unspecified → All
Isn't this e10s regression.
Maybe. It's still working on Mac even with e10s on though, so there must be something Linux-specific here.
I have the feeling it's been like this for a long time. I remember having seen issues like this one for long.
I cannot reproduce this bug in Firefox Nightly on Ubuntu. Mouse capturing is working fine.

What distribution / desktop manager are you using?
Component: Event Handling → Widget: Gtk
Hi, it's Debian/Gnome.
Works fine for me on Debian 8 with Gnome 3.14.1 too, with e10s on or off. I'm testing in a VirtualBox VM.
User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:52.0) Gecko/20100101 Firefox/52.0
User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:55.0) Gecko/20100101 Firefox/55.0

I have tested your issue on latest Firefox release v52 and latest Nightly (Build ID: 20170324110206) and could not reproduce it. I have followed the steps from comment 0 and also from comment 3 and tried them with e10s ON and OFF. I've also tested this on Windows 8.1 with latest Nightly build and all worked fine.
Assignee: nobody → mstange
Assignee: mstange → nobody

    
    

    
  
Markus, the selection works correctly for me as well.
But please try my initial testcase in comment 0 or jsbin in comment 3.

Something I should have said earlier: I'm using the "sloppy mouse focus" mode to handle windows' focus. So when the mouse cursor leaves the window, it also loses the focus.

    
    

    
  
It's difficult to show on a screen recording because everything happens as if the mouse button is not released... which we don't see on the screen capture :)

    
    

    
  
But you can see at which point the type=mouseup message appears.
I will try the sloppy mouse focus setting.

    
    

    
  


  
Sorry Markus I missed that you tried the testcase too :)

here is my own recording.
Assignee: nobody → felash

    
  
Assignee: felash → nobody

    
    

    
  
That does the trick. I can now reproduce the bug.

I used "apt-get install dconf-tools" to install the dconf Editor, opened the dconf Editor, navigated to org -> gnome -> desktop -> wm -> preferences, and set "focus-mode" to "sloppy".
Summary: It's difficult to track the mouse position when it goes out of the browser window → Mouse capturing does not work with org.gnome.desktop.wm.preferences focus-mode set to 'sloppy'

    
    

    
  
Chrome doesn't lose the focus when doing the same thing, but Firefox does. So that's likely the root cause here.

    
    

    
  
So it sounds like the problem is that Firefox allows itself to lose focus while the mouse is captured.

Karl, do you know how hard it would be to fix this?
Flags: needinfo?(karlt)

    
    

    
  
I've also tested text selection in Terminal. Terminal doesn't lose focus if the mouse moves over a different window while the mouse button is down.

    
    

    
  
The testcase above doesn't use setCapture, but attach events on document. Chrome seems to use this to decide whether the mouse should be captured and I think we should do the same for compatibility (Chrome doesn't have setCapture).

I'll attach another testcase that uses setCapture, the behavior is slightly different IIRC.

    
    

    
  
Neil might recall something about this.

    
    

    
  


  
Same behavior actually.
Assignee: nobody → felash

    
  
Assignee: felash → nobody

    
    

    
  
I don't think it is clear at this stage which is the cause and effect between
focus and mouse capture breaking.

If the window manager is either switching focus or breaking capture while the
mouse is down, then that is most likely a bug in the window manager.  FWIW
there is no problem with kwin and its Focus Follow Mouse policies, which
correspond to "sloppy".

X11 provides that mouse events from ButtonPress to ButtonRelease are
delivered to the same client unless something explicitly requests otherwise,
and I expect it is difficult for a different client to steal the events.

The observation that Chrome and Terminal don't lose focus raises the
question of what Firefox is doing differently.

NSPR_LOG_MODULES=timestamp,Widget:5,WidgetFocus:5 in the environment for
Firefox may or may not provide some clues.

Does "GDK_CORE_DEVICE_EVENTS=1 gtk3-demo" lose focus during mouse selection
when the mouse moves over the window of another client?
Flags: needinfo?(karlt)

    
    

    
  
(In reply to Julien Wajsberg [:julienw] from comment #13)
> Markus, the selection works correctly for me as well.

If selection in Firefox works correctly, but the testcase does not, then I guess there must be something Firefox is doing different.

Is the behavior the same with and without e10s?

    
    

    
  
Here is the log with NSPR_LOG_MODULES=timestamp,Widget:5,WidgetFocus:5 in latest nightly while doing the STR in comment 0.

2017-03-27 09:33:26.132064 UTC - 1071384384[7f273e7a44a0]: OnEnterNotify: 7f2717f62000
2017-03-27 09:33:26.158503 UTC - 1071384384[7f273e7a44a0]: OnContainerFocusInEvent [7f2717f62000]
2017-03-27 09:33:26.170694 UTC - 1071384384[7f273e7a44a0]:   SetFocus 0 [7f2717f62000]
2017-03-27 09:33:26.170725 UTC - 1071384384[7f273e7a44a0]:   widget now has focus in SetFocus() [7f2717f62000]
2017-03-27 09:33:26.171059 UTC - 1071384384[7f273e7a44a0]: GetScreenBounds 199,27 | 1717x904
2017-03-27 09:33:26.171256 UTC - 1071384384[7f273e7a44a0]: Events sent from focus in event [7f2717f62000]
2017-03-27 09:33:26.171465 UTC - 1071384384[7f273e7a44a0]: nsWindow::OnWindowStateEvent [7f2717f62000] changed 128 new_window_state 128
2017-03-27 09:33:26.171527 UTC - 1071384384[7f273e7a44a0]: nsWindow::OnWindowStateEvent [7f2717f62000] changed 128 new_window_state 128
2017-03-27 09:33:28.711497 UTC - 1071384384[7f273e7a44a0]: Button 1 press on 7f2717f62000
2017-03-27 09:33:29.389613 UTC - 1071384384[7f273e7a44a0]: OnLeaveNotify: 7f2717f62000
2017-03-27 09:33:29.820561 UTC - 1071384384[7f273e7a44a0]: OnContainerFocusOutEvent [7f2717f62000]
2017-03-27 09:33:29.829128 UTC - 1071384384[7f273e7a44a0]: Done with container focus out [7f2717f62000]
2017-03-27 09:33:29.839007 UTC - 1071384384[7f273e7a44a0]: nsWindow::OnWindowStateEvent [7f2717f62000] changed 128 new_window_state 0
2017-03-27 09:33:29.839034 UTC - 1071384384[7f273e7a44a0]: nsWindow::OnWindowStateEvent [7f2717f62000] changed 128 new_window_state 0
2017-03-27 09:33:30.098662 UTC - 1071384384[7f273e7a44a0]: Button 1 release on 7f2717f62000
2017-03-27 09:33:30.099301 UTC - 1071384384[7f273e7a44a0]: OnLeaveNotify: 7f2717f62000
2017-03-27 09:33:30.619319 UTC - 1071384384[7f273e7a44a0]: OnEnterNotify: 7f2717f62000
2017-03-27 09:33:31.671705 UTC - 1071384384[7f273e7a44a0]: GetScreenBounds 199,27 | 1717x904
2017-03-27 09:33:31.671909 UTC - 1071384384[7f273e7a44a0]: GetScreenBounds 199,27 | 1717x904
2017-03-27 09:33:31.671990 UTC - 1071384384[7f273e7a44a0]: GetScreenBounds 199,27 | 1717x904
2017-03-27 09:33:31.672066 UTC - 1071384384[7f273e7a44a0]: GetScreenBounds 199,27 | 1717x904
2017-03-27 09:33:32.308204 UTC - 1071384384[7f273e7a44a0]: OnContainerFocusInEvent [7f2717f62000]
2017-03-27 09:33:32.321205 UTC - 1071384384[7f273e7a44a0]:   SetFocus 0 [7f2717f62000]
2017-03-27 09:33:32.321243 UTC - 1071384384[7f273e7a44a0]:   widget now has focus in SetFocus() [7f2717f62000]
2017-03-27 09:33:32.321560 UTC - 1071384384[7f273e7a44a0]: GetScreenBounds 199,27 | 1717x904
2017-03-27 09:33:32.321928 UTC - 1071384384[7f273e7a44a0]: Events sent from focus in event [7f2717f62000]
2017-03-27 09:33:32.324646 UTC - 1071384384[7f273e7a44a0]: nsWindow::OnWindowStateEvent [7f2717f62000] changed 128 new_window_state 128
2017-03-27 09:33:32.324665 UTC - 1071384384[7f273e7a44a0]: nsWindow::OnWindowStateEvent [7f2717f62000] changed 128 new_window_state 128
2017-03-27 09:33:32.366572 UTC - 1071384384[7f273e7a44a0]: Button 1 press on 7f2717f62000
2017-03-27 09:33:32.440161 UTC - 1071384384[7f273e7a44a0]: Button 1 release on 7f2717f62000
2017-03-27 09:33:36.173533 UTC - 1071384384[7f273e7a44a0]: OnLeaveNotify: 7f2717f62000
2017-03-27 09:33:36.258184 UTC - 1071384384[7f273e7a44a0]: OnContainerFocusOutEvent [7f2717f62000]
2017-03-27 09:33:36.266483 UTC - 1071384384[7f273e7a44a0]: Done with container focus out [7f2717f62000]
2017-03-27 09:33:36.274514 UTC - 1071384384[7f273e7a44a0]: nsWindow::OnWindowStateEvent [7f2717f62000] changed 128 new_window_state 0
2017-03-27 09:33:36.274549 UTC - 1071384384[7f273e7a44a0]: nsWindow::OnWindowStateEvent [7f2717f62000] changed 128 new_window_state 0

    
    

    
  
(In reply to Karl Tomlinson (:karlt) from comment #24)

> Does "GDK_CORE_DEVICE_EVENTS=1 gtk3-demo" lose focus during mouse selection
> when the mouse moves over the window of another client?

Yes it does.
It doesn't without `GDK_CORE_DEVICE_EVENTS=1`.

> Is the behavior the same with and without e10s?

Ah ! It actually works as expected without e10s !
When the mouse is out of the window, Firefox loses the focus but still gets the mouse events: all the "mousemove" events and the last "mouseup" event too.

I'm using a e10s-enabled build for several years, that's likely why I see this bug for a very long time. That's reassuring to know that our release users likely didn't see this much.

    
    

    
  
Verbose logs without e10s:


2017-03-27 09:42:44.630209 UTC - 2036623168[7f1977fa44a0]: OnEnterNotify: 7f195128e000
2017-03-27 09:42:44.909629 UTC - 2036623168[7f1977fa44a0]: OnContainerFocusInEvent [7f195128e000]
2017-03-27 09:42:44.919904 UTC - 2036623168[7f1977fa44a0]:   SetFocus 0 [7f195128e000]
2017-03-27 09:42:44.919945 UTC - 2036623168[7f1977fa44a0]:   widget now has focus in SetFocus() [7f195128e000]
2017-03-27 09:42:44.920165 UTC - 2036623168[7f1977fa44a0]: GetScreenBounds 199,27 | 1717x904
2017-03-27 09:42:44.920463 UTC - 2036623168[7f1977fa44a0]: Events sent from focus in event [7f195128e000]
2017-03-27 09:42:44.920912 UTC - 2036623168[7f1977fa44a0]: nsWindow::OnWindowStateEvent [7f195128e000] changed 128 new_window_state 128
2017-03-27 09:42:44.920928 UTC - 2036623168[7f1977fa44a0]: nsWindow::OnWindowStateEvent [7f195128e000] changed 128 new_window_state 128
2017-03-27 09:42:45.793072 UTC - 2036623168[7f1977fa44a0]: Button 1 press on 7f195128e000
2017-03-27 09:42:46.412158 UTC - 2036623168[7f1977fa44a0]: OnLeaveNotify: 7f195128e000
2017-03-27 09:42:46.725246 UTC - 2036623168[7f1977fa44a0]: OnContainerFocusOutEvent [7f195128e000]
2017-03-27 09:42:46.731152 UTC - 2036623168[7f1977fa44a0]: Done with container focus out [7f195128e000]
2017-03-27 09:42:46.741210 UTC - 2036623168[7f1977fa44a0]: nsWindow::OnWindowStateEvent [7f195128e000] changed 128 new_window_state 0
2017-03-27 09:42:46.741228 UTC - 2036623168[7f1977fa44a0]: nsWindow::OnWindowStateEvent [7f195128e000] changed 128 new_window_state 0
2017-03-27 09:42:47.201743 UTC - 2036623168[7f1977fa44a0]: nsWindow [7f1933086c00]
2017-03-27 09:42:47.201770 UTC - 2036623168[7f1977fa44a0]: 	mShell 7f1933089660 mContainer 7f1931f762d0 mGdkWindow 7f19334d2370 0x120002f
2017-03-27 09:42:49.454471 UTC - 2036623168[7f1977fa44a0]: Button 1 release on 7f195128e000
2017-03-27 09:42:49.455943 UTC - 2036623168[7f1977fa44a0]: OnLeaveNotify: 7f195128e000
2017-03-27 09:42:49.945175 UTC - 2036623168[7f1977fa44a0]: OnEnterNotify: 7f195128e000
2017-03-27 09:42:50.400661 UTC - 2036623168[7f1977fa44a0]: OnContainerFocusInEvent [7f195128e000]
2017-03-27 09:42:50.409612 UTC - 2036623168[7f1977fa44a0]:   SetFocus 0 [7f195128e000]
2017-03-27 09:42:50.409643 UTC - 2036623168[7f1977fa44a0]:   widget now has focus in SetFocus() [7f195128e000]
2017-03-27 09:42:50.409932 UTC - 2036623168[7f1977fa44a0]: GetScreenBounds 199,27 | 1717x904
2017-03-27 09:42:50.410054 UTC - 2036623168[7f1977fa44a0]: Events sent from focus in event [7f195128e000]
2017-03-27 09:42:50.410320 UTC - 2036623168[7f1977fa44a0]: nsWindow::OnWindowStateEvent [7f195128e000] changed 128 new_window_state 128
2017-03-27 09:42:50.410332 UTC - 2036623168[7f1977fa44a0]: nsWindow::OnWindowStateEvent [7f195128e000] changed 128 new_window_state 128
2017-03-27 09:42:51.303949 UTC - 2036623168[7f1977fa44a0]: OnLeaveNotify: 7f195128e000
2017-03-27 09:42:51.550088 UTC - 2036623168[7f1977fa44a0]: OnContainerFocusOutEvent [7f195128e000]
2017-03-27 09:42:51.556262 UTC - 2036623168[7f1977fa44a0]: Done with container focus out [7f195128e000]
2017-03-27 09:42:51.566074 UTC - 2036623168[7f1977fa44a0]: nsWindow::OnWindowStateEvent [7f195128e000] changed 128 new_window_state 0
2017-03-27 09:42:51.566096 UTC - 2036623168[7f1977fa44a0]: nsWindow::OnWindowStateEvent [7f195128e000] changed 128 new_window_state 0

    
    

    
  
The difference in focus state with and without GDK_CORE_DEVICE_EVENTS=1 may be
a bug in the window manager or GTK.

However, this bug is about the mouse events.
The difference in behaviour between parent and child processes implies this
is not a bug in widget/gtk code.

The key question then is why does Gecko change the event target for mouse
events when focus is lost when (and only when) e10s is enabled?
Component: Widget: Gtk → Event Handling

    
    

    
  
Regression from e10s. (Is there a bug to block ?)
Keywords: regressionwindow-wanted → regression
Blocks: e10s

    
    

    
  
Moving to p3 because no activity for at least 1 year(s).
See https://github.com/mozilla/bug-handling/blob/master/policy/triage-bugzilla.md#how-do-you-triage for more information
Priority: P2 → P3

    
    

    
  
This is still happening BTW.
Component: Event Handling → User events and focus handling

    
  
Severity: normal → S3

          You need to log in
          before you can comment on or make changes to this bug.
        






  

    
  







  

    

      
Attachment

      

      
      
      
      
    

    

      

        

          

            
General

            

              Creator: 



            

            
Created: 

            
Updated: 

            
Size: