GNOME Bugzilla – Bug 709914
Cannot move windows on touchscreen (except from WM decorations)
Last modified: 2014-03-17 17:25:18 UTC
With the new way nautilus windows are decorated, they cannot be moved. The new buttons work, the close (X) button works, but cannot drag the window. Dragging normal windows work, only the new "all in one bar"-styled windows are stuck. Tested on fedora 20.
forgot to mention (only in the title) that it's on a touchscreen. With a mouse it works fine.
What about other applications with the "all in one bar" (also known as Header Bar), such as gnome-system-monitor and gnome-control-center? Is nautilus the only application with this problem?
Happens with all of them. Tried with the weather app, and same. Cannot be moved with touch. When i dock the tablet, i can use the mouse (Iconia tab W500) to drag it. But still doesn't work using touch. Also, on Arch it behaves the same way. (only tried 64 bit installs).
gnome expects applications to implement stuff for touchscreens? stuff like rightclick, drag, even the on-screen keyboard poping up. because while the above mentioned things work in normal (standard) gnome apps, they dont work on other applications (like chromium) or the new Header Bar. (not even right click on files). seems very strange that gnome wants applications to implement this stuff, when they should be done by the DE.. i dont know if this is a bug or a "feature"..
(In reply to comment #3) > Happens with all of them. Tried with the weather app, and same. Cannot be moved > with touch. Ok, this means the bug is not in nautilus, but I'm still not sure where it may be, so I will ask two more questions that will help triage this bug: 1- Using the touchscreen, can you move a maximized gedit window by dragging from the empty space in the toolbar? Or is the titlebar the only place you can drag from? 2- Which gtk+ theme are you using? Can you test if this bug happens with other themes? In particular, do you see this bug with the default GNOME theme ("Adwaita")? Thanks in advance for testing. (In reply to comment #4) > i dont know if this is a bug or a "feature".. If I understood your report correctly, this can only be a bug. Let's stick to the point and find out where it comes from so that a resolution can be reached. :)
1- I cannot drag from the empty space (where you have File Edit View ..) only from the title bar ( probably the Header Bar is an extension of the menu bar, instead of the title bar..) 2- only tryed it with adwaita (and high contrast) as they are the only ones i can choose from. Also i found a new bug (probably unrelated) where if i have 2 windows (normal styled windows) on screen (terminal and gedit for example) and i maximize one (lets say gedit) and i minimize it back, when i press on the title bar of terminal, it moves the gedit window. Should i post this as a new bug, or is it fine this way? btw, i dont need to maximize/minimize, but i do need to play with them a little (move around) for it to mixup the input. again, only happens with touchscreen, not with mouse.
(In reply to comment #6) > 1- I cannot drag from the empty space (where you have File Edit View ..) only > from the title bar ( probably the Header Bar is an extension of the menu bar, > instead of the title bar..) Then it is the same bug. Just to double check, if you use the mouse, you can drag from empty space in the menu bar, right? > 2- only tryed it with adwaita (and high contrast) as they are the only ones i > can choose from. That's good enough, it excludes a third party theme as a cause. I'm moving this to gtk+. Also updating the title. > Also i found a new bug (probably unrelated) where if i have 2 windows (normal > styled windows) on screen (terminal and gedit for example) and i maximize one > (lets say gedit) and i minimize it back, when i press on the title bar of > terminal, it moves the gedit window. Should i post this as a new bug, or is it > fine this way? A new bug is a better idea, because it may be unrelated. I'd report it against "mutter" (assuming you use gnome-shell).
Thank you
Could bug 709947 be related?
probably not, as this bug affects the new Header Bar, and that bug affects only the old styled windows. although at the moment, i cannot move the Header Bar Window..
not easily fixable. the ewmh expects client-initiated window moves to be triggered by a button or key event.
ive noticed.. this happens with the on-screen keyboard, with touch-scrolling also.. seems like a big flaw in design in my opinion. how about adding an option to disable the header bar? honestly, i like it. On my desktop it's really nice but since it doesnt work on my tab.. couldnt i get an option to disable it?
no
so this most probably wont be fixed? Meaning gnome3 will never work with touch?
*** Bug 711861 has been marked as a duplicate of this bug. ***
*** Bug 712209 has been marked as a duplicate of this bug. ***
(In reply to comment #14) > so this most probably wont be fixed? Meaning gnome3 will never work with touch? No. I said it is not easily fixable. Thats different from 'will never be fixed'.
Beside the fact that it is currently not usable on a touch screen device there does not seems to be a HIG for the headerbar. Simple applications like control center do offer enough space for the finger to move the window. On the other side applications like nautilus with some sub directories does not have such finger space. Is there a hint for me to start working/fixing this problem?
Same problem here with my Surface Pro + Ubuntu GNOME + Gnome 3.10. It's very annoying, because the Header Bar seems pretty good for touch. It makes the whole touch experience mostly unusable (this one + bug 709947). I would really like to help working on that. Any hint would be very helpful. Thanks.
From my investigation the problem seems to lie on the mutter side of the EWMH implementation, GTK+ sends a _NET_WM_MOVERESIZE message correctly, but mutter double checks the button mask through XIQueryPointer at https://git.gnome.org/browse/mutter/tree/src/core/window.c#n6724, just in case the button was quickly released before the message arrived to the WM. But XIQueryPointer doesn't account for the button 1 being virtually pressed through touch events, so the request is dismissed. The problem rather seems to be in X, but I'm moving this bug to mutter for now until I check if this is intended behavior on XI2.2 or not.
But why is it working for the old GTK window decoration? Isn't it the same flow? If not then GTK+ needs to be changed to use the same old flow for headerbars.
(In reply to comment #21) > But why is it working for the old GTK window decoration? Isn't it the same > flow? If not then GTK+ needs to be changed to use the same old flow for > headerbars. In the server-side decorations case, there's no race at all. We get a ButtonPress, and we have the implicit button grab, so we're guaranteed to get the ButtonRelease later at some point. With client-side decorations, the client processes the ButtonPress, and sends a _NET_WM_MOVERESIZE client message, but it's possible that the client can receive a ButtonRelease before the WM has a chance to process the _NET_WM_MOVERESIZE event. We'll take a grab when it's too late. This isn't necessarily new to header bars, mind you. The same race also happened when e.g. clicking on the empty space of a menu bar.
I've seen nothing in the XI2 spec about or against pointer emulation behavior on device queries, and seeing the core protocol queries don't expose this behavior, I've made an xserver patch to fix this: http://lists.x.org/archives/xorg-devel/2014-January/039781.html
I'm also seeing this issue. To add to question 1 of comment #5: I can double-tab the headerbar and the window maximizes. I can then drag it from the black top panel and move the window around the screen. (Ubuntu-Gnome 14.04 daily 2.2.2014, Adwaita theme)
*** Bug 723880 has been marked as a duplicate of this bug. ***
Created attachment 271789 [details] [review] x11: Fallback to emulated window dragging for touch devices Sadly, EWMH moveresize mechanism can't work with touch devices for two reasons: 1) As a mutter implementation detail, the device is queried in order to check whether the dragging button is still pressed. Touch devices won't report the button 1 being pressed through pointer emulation. 2) Even bypassing that check, on X11 touch events are selected prior to sequences being started, either through XISelectEvents or XIGrabTouchBegin, no late registering through active grabs is allowed, as WMs do on reaction to EWMH moveresize messages. So for the time being, make touch devices fallback on emulated window dragging, which at least allows for moving windows.
Created attachment 271790 [details] [review] x11: Implement "drag to top to maximize" gesture on emulated window dragging And the counterpart to unmaximize when dragging a maximized window, if touch devices aren't going to use EWMH moveresize, having this one at least makes things feel a bit less awkward.
Review of attachment 271789 [details] [review]: ::: gdk/x11/gdkwindow-x11.c @@ +5328,1 @@ gdk_atom_intern_static_string ("_NET_WM_MOVERESIZE"))) Can we extract this check into a common function, like should_do_ewmh_drag()?
Review of attachment 271790 [details] [review]: ugh, I do not like this at all. Wouldn't this fail for windows with a max size hint?
Sadly, drag-to-tile-left/right does not work, and we don't get the nice tile animations for maximize either. But still, being able to drag csd windows is a big improvement.
Would it be an alternative worth exploring to set a property like _MUTTER_TOUCH_INITIATED_OPERATION before starting the ewmh operation and have mutter check that ?
(In reply to comment #29) > Review of attachment 271790 [details] [review]: > > ugh, I do not like this at all. Wouldn't this fail for windows with a max size > hint? It doesn't. I've min/max size hints to tests/testimage, so you can try for yourself. I think the draggability is a big enough win on touch that we should use this approach for 3.12. I'd like to investigate a) adding similar tiling support when pushing against the left or right edge b) possibly getting the shell animation back by adding some private protocol between gtk and the shell But these can be done as followups - just do the small refactoring Jasper asked for before pushing this.
I think this is a good short-term plan, but we should investigate simply having a replacement to _NET_BEGIN_MOVERESIZE for touch, and build proper touch support in mutter. I don't want to see this approach used long-term.
(In reply to comment #33) > I think this is a good short-term plan, but we should investigate simply having > a replacement to _NET_BEGIN_MOVERESIZE for touch, and build proper touch > support in mutter. I don't want to see this approach used long-term. Sure. But as Carlos explained in comment 26, the _NET_BEGIN_MOVERESIZE approach of client-message + active grab doesn't work for touch.
I refactored that as said and pushed, will be thinking on a more proper way for 3.14... Attachment 271789 [details] pushed as d1d4c60 - x11: Fallback to emulated window dragging for touch devices Attachment 271790 [details] pushed as 41b73e4 - x11: Implement "drag to top to maximize" gesture on emulated window dragging