Based on my tests just now, the workaround was broad enough that it still functions as expected now. I'll be putting out a 19.8 release soon, but this is independent of any EFL releases.
On Fri, Jul 31, 2015 at 5:38 AM, Stefan Schmidt <ste...@osg.samsung.com> wrote: > Hello. > > On 30/07/15 07:20, Jean-Philippe André wrote: > > Hi, > > > > On Thu, Jul 30, 2015 at 9:09 AM, Dave <d...@flex.com.au> wrote: > > > >> In the year 2015, of the month of July, on the 29th day, Michael > >> Blumenkrantz wrote: > >>> There were a number of issues here, and the only case I found which > >> triggered > >>> them was to run Enlightenment with click focus policy (due to how x11 > >> grabs are > >>> used. The reporter of the issue for 19.6 was using this, as do I, which > >> is why > >>> it was easy for us to notice. > >> Behaviour was also triggered with a sloppy focus policy. That's what > I > >> had > >> configured when I noticed the issue. > >> > >>> IIRC there were two main issues: > >>> > >>> 1) mouse event sequencing was rewritten - previous behavior when > >> clicking the > >>> mouse went something like DOWN UP, but now if there is a modified > down > >> event > >>> (eg. DOUBLE DOWN), "fake" UP events are added before each new DOWN. > >> This > >>> caused internal windows to interpret clicks differently in certain > >> cases, > >>> such as checkbox widgets behaving as though each single click was a > >> double > >>> click. Also after a click, the mouse button would be locked in the > DOWN > >>> position at the original coordinates, preventing clicks from > triggering > >>> anywhere else on the canvas > >>> > >>> 2) fake events were added regardless of device - the way that the new > UP > >> events > >>> were added involved keeping track of the state of the mouse button, > >> but no > >>> information about which device was pressed was tracked. This > resulted > >> in > >>> issues where multiple input devices would start triggering events > for > >> each > >>> other, as well as conflicts between different EE engine events. > >>> > >>> #1 was worked around by both [adding special case behavior for internal > >> windows > >>> so that x11 grabs would apply differently and not send events] and > >> [blocking > >>> events on internal window canvases during a compositor grab]. The > 19.6-7 > >>> releases have the first fix, and the second one is pending for a 19.8 > >> release. > >>> #2 I made some changes to ee-input to track device state so that at > >> least there > >>> would not be conflicts between devices/engines. No other behavioral > >> changes > >>> were made in this commit. > >>> > >>> All "current" versions of Enlightenment (E19, E-git) will require > >> changes to > >>> continue functioning as expected if this EFL behavior is rolled back. > > > > I believe I finally understand the issue correctly and: > > - It should affect only E and potentially other compositors written in > EFL > > - EFL 1.15 should exhibit an issue with E17, E18 and E19 <= E19.5 > > > > I tested E17.6, E18.8 and E19.5 with EFL 1.15 (git). > > I played with various focus policies, too. > > I could not reproduce the issue. > > > > According to Mike, E19 < E19.6 had other bugs that may cancel this one. > > > > > > All new behaviour has now been disabled by Ji-Youn, so CANCEL will not > > happen, unnless an env var is set. > > ok, this is all now hidden behind ECORE_INPUT_CANCEL as env var. > > https://git.enlightenment.org/core/efl.git/commit/?id=be2a4342b40f7ec073c39e785c39e4c629762ef4 > > This restores the old behavior and should give us time to sort things > out before enabling it by default again. Means it can stay that way for > 1.15 and for 1.16 we can have another look. > > This would also mean that the workaround in E19 is no longer needed and > you would want to have another E19 release out before 1.15, right Mike? > I delayed until Tuesday anyway. Let me know if that works for you. > > Anybody else happy with this? > > regards > Stefan Schmidt > > > ------------------------------------------------------------------------------ > _______________________________________________ > enlightenment-devel mailing list > enlightenment-devel@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > ------------------------------------------------------------------------------ _______________________________________________ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
