Page MenuHomePhabricator

alt+left/middle mouse to move/resize breaks internal e windows
Closed, ResolvedPublic


this is new now - if i alt+left mouse drag an efm window around and i happened to have been over an efm icon when i pressed... when i release the efm icon drags. middle mouse to resize has similar bad effects to the point of stopping all input on an internal e window (efm window or other settings dialogs etc.). normal apps windows dont get the first mouse down. something has broken with filtering out these events to "self clients". (so the down goes through, the up does not leaving the window is an odd state).

raster created this task.Mar 23 2016, 10:19 PM
raster reopened this task as Open.Mar 29 2016, 9:43 PM

hmm no - now it just changed nature... go to e settings and alt+left clikc when mouse is over some menu item there like "wallpaper" or "theme" ... alt+left click and drag.

the client window gets a mouse up event. and "executes" the wallpaper click. alt+left click over close button .. window goes away. the fake mouse up is now just a different badness. :)

hahahahahah :)

woot. yup. back to being normal now. well done sir Z! :)

raster reopened this task as Open.Apr 28 2016, 8:34 AM

back open... but now instead of dnding the icon it just begins a drag-box-select even though mouse is no longer down, blue select box gets dragged around wherever the mouse goes eg in the efm window.

raster reopened this task as Open.May 10 2016, 8:56 PM

it's back. but now alt+left click on an efm widnow selects the icon - it shouldn't. window shouldn't even see the click. it's trapped by e. this also then results in alt+left click drag window around eg the control panel window, then if your mouse was over an item in the control panel, then that item gets selected and the dialog comes up.

zmike added a comment.May 11 2016, 9:18 AM

There's really not a good solution to this. Internal windows use the same event that the compositor uses, and under X11 the propagation is such that internal windows receive the event before the compositor since the engine directly receives X11 mouse input.

The best I can do off the top of my head would be to add hacks to call ecore_event_evas_shutdown() until it's dead, then start it up the same number of times in order to change the callback ordering, but this seems like it could cause issues if another compositor-side handler decides not to propagate the event before the window receives it.

this USED to work because in x11 we used passive grabs where xserver redirected then event before it got to the window. we had the passive grab on a parent window of the client win (x grab button). you have changed all of the event flow thus breaking this and creating the problem you now have. :) you can go back to using passive grabs in x11 and thus window id will be a parent window not the client thus it wont be processed as an event for the client window even within the same process. for wayland you'll have to sort it out some other way. likely when you trap events on the image obj - dont send on to client if they match a binding button entry - just like passive grabs do in x11.

zmike added a comment.May 12 2016, 8:25 AM

Ah, okay, so this was just the result of using the client window instead of the parent window for binding grabs.

Wayland has no issues with this since the compositor handles eventing correctly.

see simple! :) was correct before with parent window with grab. thats why we checked parent and client window id for matching window id's to a border... for things like passive grabs. :)