Page MenuHomePhabricator

Enlightenment sometimes loses focus
Closed, ResolvedPublic

Description

Enlightenment 0.21.99.23171 on FreeBSD 11.
I configured additional mouse buttons to switch windows (Window : List : Next Window/Previous Window). So, I active 'Window List' with an additional button, then I use mouse scroll to select a window to switch to, then I click on something to close the 'Window List' (normally, I click inside the 'Window List', but the place I click does not matter). Regularly, after such manipulation, the focus is lost. It means that the new window becomes active (window title changes color), but if I click on a control inside this window - nothing happens. Like if I just changed the focus to the window with this click. The next click works as expected. If I use keyboard to switch to another window (Alt-Tab by default) - I do not have this problem. The most interesting thing - sometimes anything works as expected, the focus is correctly passed to new window. I would say that the problem is present in 80% cases.

I don't know if it is the same problem (or I should open another ticket), but the focus is lost too after the following manipulations in Terminology (1.1.99) :

  • select something with mouse (for example, double click on a word inside Terminology window)
  • right-click on selected region - a popup is shown (Copy; Open as URL)
  • click on 'Copy' inside the popup

Terminology window becomes active again (Window title has active color), but the focus is lost, if I type something on my keyboard - nothing happens, the Terminology cursor is not active.

I tried to activate the option 'Focus last focused window on lost focus', but it does not help.

Just to precise that sometimes the focus is lost after closing a window too. Another window becomes active, but does not get a focus.

Peter2121 renamed this task from Enlightenment sometimes lose focus to Enlightenment sometimes loses focus.Nov 26 2017, 9:05 AM
zmike added a comment.Jan 9 2018, 9:54 AM

Are you able to interact with any windows at all when this occurs?

zmike triaged this task as Pending on user input priority.Jan 9 2018, 9:54 AM
zmike moved this task from Backlog to Active on the enlightenment-git board.Jan 9 2018, 10:55 AM

Yes, I can interact with other windows, but no window has focus.

I'm unable to reproduce any part of this using the mouse binding setup you described. Can you provide more info about your window configuration and focus settings?

The problem is still present in last Enlightenment (GIT) built with last EFL (GIT).
The most simple way to reproduce - add mouse bindings like I described, then start two windows on the same screen (Firefox and Thunderbird), then from Firefox activate 'Windows List' with mouse button - Thunderbird is selected and put in front), then click-left somewhere inside Thunderbird. 'Windows List' will close, Thunderbird will get focus. Click somewhere inside Thunderbird window (for example, to change the active folder) - nothing happens. The second click in the same place will work correctly.

zmike raised the priority of this task from Pending on user input to Incoming Queue.Mar 2 2018, 9:30 AM
zmike moved this task from Active to Backlog on the enlightenment-git board.

I've just tested it a little bit more.
The problem is really simple to reproduce if I click inside winlist, choosing a window to activate. The area of winlist where I click does not matter, this click just closes winlist.
So:

  1. Additional mouse button to activate winlist
  2. Mouse wheel to choose window
  3. Mouse left-click inside winlist
  4. Selected window becomes active (decoration), but the first click inside the window does not work (no focus), only the second one.

Sometimes E loose focus after closing window, but I still cannot find a sequence to reproduce it in 100% cases. The situation is globally the same - the decoration shows the window as active, but the first click inside the window does not work, only the second click.

Some additional tests with EFL 1.21.1, Enlightenment 0.22.4 on FreeBSD 12BETA2.
The problem is still present.
Really interesting point is that the problem is not present on FIRST task switch. If I open some windows and then use WinList with mouse only - everything works as expected. If I then retry - the focus is lost as explained. And if then I use WinList with keyboard (Alt-Tab) - the next time I use it with mouse it works OK - once.

Please, fix it!

this happens to me especially on high system load on linux (video rendering, swapping) and then i see enlightenment is using half of my cpu. most of the times this happens the only way to recover is to restart enlightenment.

if it happens i can switch windows with Tasks, but any click/input inside the window itself is not transfered to the window.

i'll try to gdb into enlightenment next time this happens.

For me it is neither related to the system charge nor to CPU use by Enlightenment.
It seems to be a bug in WinList module as it cannot be produced by keyboard manipulations, only by mouse.

i actually feared it was this again... X not answering enlightenments call.

i don't have a reliable test case, but here it appears to be a race when $PROGRAM is displaying a tooltip, because the tooltip stays visible over every program. reminds me of T3444, only this time it's firefox.

bt

#0  0x00007fbd30f972c9 in poll () at /lib64/libc.so.6
#1  0x00007fbd2d60dcc7 in  () at /usr/lib64/libxcb.so.1
#2  0x00007fbd2d60f9da in xcb_wait_for_special_event () at /usr/lib64/libxcb.so.1
#3  0x00007fbd288f1cbb in  () at /usr/lib64/libEGL_mesa.so.0
#4  0x00007fbd288f1e08 in  () at /usr/lib64/libEGL_mesa.so.0
#5  0x00007fbd288f27e2 in  () at /usr/lib64/libEGL_mesa.so.0
#6  0x00007fbd288f390b in  () at /usr/lib64/libEGL_mesa.so.0
#7  0x00007fbd288e5696 in  () at /usr/lib64/libEGL_mesa.so.0
#8  0x00007fbd288dcdac in eglQuerySurface () at /usr/lib64/libEGL_mesa.so.0
#9  0x00007fbd2917e354 in eng_outbuf_swap_mode (ob=0x5562e0c9c880) at modules/evas/engines/gl_x11/evas_x_main.c:1394
#10 0x00007fbd31efe003 in  () at /usr/lib64/libevas.so.1
#11 0x00007fbd31e34051 in  () at /usr/lib64/libevas.so.1
#12 0x00007fbd31e35a52 in  () at /usr/lib64/libevas.so.1
#13 0x00007fbd31e3627c in  () at /usr/lib64/libevas.so.1
#14 0x00007fbd31db6e1a in evas_canvas_render_updates () at /usr/lib64/libevas.so.1
#15 0x00007fbd29190005 in _ecore_evas_x_render (ee=0x5562e0bda190) at modules/ecore_evas/engines/x/ecore_evas_x.c:805
#16 0x00007fbd324d1210 in  () at /usr/lib64/libecore_evas.so.1
#17 0x00007fbd318b7abf in  () at /usr/lib64/libecore.so.1
#18 0x00007fbd30e9d11e in _event_callback_call
    (legacy_compare=0 '\000', event_info=<optimized out>, desc=0x7fbd318e9f60 <_EFL_LOOP_EVENT_IDLE_ENTER>, pd=0x5562e09d4be0, obj_id=<optimized out>)
    at lib/eo/eo_base_class.c:1473
#19 0x00007fbd30e9d11e in _efl_object_event_callback_call
    (obj_id=<optimized out>, pd=0x5562e09d4be0, desc=0x7fbd318e9f60 <_EFL_LOOP_EVENT_IDLE_ENTER>, event_info=<optimized out>) at lib/eo/eo_base_class.c:1557
#20 0x00007fbd30e9879e in efl_event_callback_call (obj=0x400000000475, desc=0x7fbd318e9f60 <_EFL_LOOP_EVENT_IDLE_ENTER>, event_info=0x0)
    at lib/eo/eo_base_class.c:1560
#21 0x00007fbd318bb364 in  () at /usr/lib64/libecore.so.1
#22 0x00007fbd318bb61f in ecore_main_loop_begin () at /usr/lib64/libecore.so.1
#23 0x00005562dee617c5 in main (argc=<optimized out>, argv=<optimized out>) at src/bin/e_main.c:1092

bt full

#0  0x00007fbd30f972c9 in poll () at /lib64/libc.so.6
#1  0x00007fbd2d60dcc7 in  () at /usr/lib64/libxcb.so.1
#2  0x00007fbd2d60f9da in xcb_wait_for_special_event () at /usr/lib64/libxcb.so.1
#3  0x00007fbd288f1cbb in  () at /usr/lib64/libEGL_mesa.so.0
#4  0x00007fbd288f1e08 in  () at /usr/lib64/libEGL_mesa.so.0
#5  0x00007fbd288f27e2 in  () at /usr/lib64/libEGL_mesa.so.0
#6  0x00007fbd288f390b in  () at /usr/lib64/libEGL_mesa.so.0
#7  0x00007fbd288e5696 in  () at /usr/lib64/libEGL_mesa.so.0
#8  0x00007fbd288dcdac in eglQuerySurface () at /usr/lib64/libEGL_mesa.so.0
#9  0x00007fbd2917e354 in eng_outbuf_swap_mode (ob=0x5562e0c9c880) at modules/evas/engines/gl_x11/evas_x_main.c:1394
        swap_mode = <optimized out>
        age = 0
#10 0x00007fbd31efe003 in  () at /usr/lib64/libevas.so.1
#11 0x00007fbd31e34051 in  () at /usr/lib64/libevas.so.1
#12 0x00007fbd31e35a52 in  () at /usr/lib64/libevas.so.1
#13 0x00007fbd31e3627c in  () at /usr/lib64/libevas.so.1
#14 0x00007fbd31db6e1a in evas_canvas_render_updates () at /usr/lib64/libevas.so.1
#15 0x00007fbd29190005 in _ecore_evas_x_render (ee=0x5562e0bda190) at modules/ecore_evas/engines/x/ecore_evas_x.c:805
        updates = <optimized out>
        rend = <optimized out>
        ee = 0x5562e0bda190
        render2 = 0
        edata = <optimized out>
        render2 = 0
#16 0x00007fbd324d1210 in  () at /usr/lib64/libecore_evas.so.1
#17 0x00007fbd318b7abf in  () at /usr/lib64/libecore.so.1
#18 0x00007fbd30e9d11e in _event_callback_call
    (legacy_compare=0 '\000', event_info=<optimized out>, desc=0x7fbd318e9f60 <_EFL_LOOP_EVENT_IDLE_ENTER>, pd=0x5562e09d4be0, obj_id=<optimized out>)
    at lib/eo/eo_base_class.c:1473
        it = 0x7fbd318ec430
        ev = {object = 0x400000000475, desc = 0x7fbd318e9f60 <_EFL_LOOP_EVENT_IDLE_ENTER>, info = 0x0}
        ret = 1 '\001'
        frame = {<No data fields>}
        cb = 0x5562e0998de8
        lookup = 0x7ffe2f6c7ad0
        saved = {__in_list = {next = 0x0, prev = 0x0, last = 0x7ffe2f6c7ad0}, desc = 0x7fbd318e9f60 <_EFL_LOOP_EVENT_IDLE_ENTER>, current = 1}
        idx = 2
        callback_already_stopped = 0 '\000'
#19 0x00007fbd30e9d11e in _efl_object_event_callback_call
    (obj_id=<optimized out>, pd=0x5562e09d4be0, desc=0x7fbd318e9f60 <_EFL_LOOP_EVENT_IDLE_ENTER>, event_info=<optimized out>) at lib/eo/eo_base_class.c:1557
#20 0x00007fbd30e9879e in efl_event_callback_call (obj=0x400000000475, desc=0x7fbd318e9f60 <_EFL_LOOP_EVENT_IDLE_ENTER>, event_info=0x0)
    at lib/eo/eo_base_class.c:1560
        _r = <optimized out>
        ___cache = {<No data fields>}
        ___call = 
          {eo_id = 0x400000000475, obj = 0x5562e09d4ba0, func = 0x7fbd30e9cf70 <_efl_object_event_callback_call>, data = 0x5562e09d4be0, extn1 = 0x1, extn2 = 0x7fbd318d05b2, extn3 = 0x0, extn4 = 0x41240e0c00000000}
        _func_ = <optimized out>
#21 0x00007fbd318bb364 in  () at /usr/lib64/libecore.so.1
#22 0x00007fbd318bb61f in ecore_main_loop_begin () at /usr/lib64/libecore.so.1
#23 0x00005562dee617c5 in main (argc=<optimized out>, argv=<optimized out>) at src/bin/e_main.c:1092
        safe_mode = 0 '\000'
        waslocked = 0 '\000'
        strshare = <optimized out>
        t = 1541587233.2479651
        tstart = 1541587233.2479651
        s = <optimized out>
        buff = "1541587233.2", '\000' <repeats 19 times>
        action = 
          {__sigaction_handler = {sa_handler = 0x5562def3f3f0 <e_sigabrt_act>, sa_sigaction = 0x5562def3f3f0 <e_sigabrt_act>}, sa_mask = {__val = {0 <repeats 16 times>}}, sa_flags = -1073741820, sa_restorer = 0x0}
        __FUNCTION__ = "main"
Detaching from program: /usr/bin/enlightenment, process 28217
[Inferior 1 (process 28217) detached]
raster added a comment.Nov 8 2018, 9:46 AM

@ProhtMeyhet - you have a different issue but yes - xserver is not responding. it's hung. that is a "driver issue" really. not much we can do about that. we're asking for the surface attributes to figure out what to render (we need to know how old the buffer is). we never get an answer... nothing we can do there. :(

raster closed this task as Resolved.Nov 9 2018, 2:06 PM

@Peter2121 - try git master now. it's working reliably for me with mouse wheel and mouse buttons bound appropriately to contexts... :)

Sorry, raster, the problem is still present with the GIT version with your modifs.
Only the first time switching windows with mouse and WinList the focus is not lost. Then it is always lost till I use once Alt-Tab. Then it is not lost once etc.

Peter2121 reopened this task as Open.Nov 10 2018, 10:50 AM

are you sure you're using git master? i am using it here - i bound both my 2nd wheel and an extra 2 mouse buttons to "window : list" -> next window / previous window. it works like a charm... i also bound some extra unused key on my keyboard to "next window" and that works the same way. the window list comes up and stays up. arrow keys allow me to move focus spatially (up goes to the next window vertically, down, next down vertically, left/right the same). escape exits the window switcher. i can keep using wheel/bound mouse buttons to iterate over windows in the list too... and it works again and again and again...

Peter2121 added a comment.EditedNov 11 2018, 3:28 AM

raster,

I've just used 'git clone' command to clone the repository.
I think I'm on 'master' as I see your last modif in src/modules/winlist/e_mod_main.c:
static Eina_Bool _e_mod_action_winlist_wheel_cb(...

I think that you did not understand exactly my issue.
As in your scenario, the window list comes up and stays up after click on the bound extra button. Then I always use scroll wheel to navigate over windows in the list - it works correctly too. Always. Then I click with the left mouse button on any place of the desktop to close window switcher (I tried to click inside the switcher or outside - into the selected window - it seems to work exactly the same way), window switcher closes and the selected window seems to get focus. The window title has all the attributes of focused window, even keyboard works correctly in this window. BUT the first mouse click inside this window is LOST. The second click works as expected. And this problem is NOT present during the FIRST using of WinList on such manner. I can reset the counter, using Alt-Tab for windows switching - it works once after switching using Alt-Tab.

any click to dismiss the alt-tab (winlist) thing will be lost - it's a click that dismisses it too like escape key. that is by design and intent, and it works that way from the frist time i use winlist (if activated by a mouse e.g. button or wheel event). if activated by a key then the mouse is not grabbed/blocked this way and can be used to click on things like alt+left mouse to move a window around. e.g use alt+tab or a key bound to nest/prev window...

raster,
Sure, the click to dismiss winlist must be lost, I don't count it. I perfectly understand that it is used like 'escape' key. I mean the next click is lost.

I mentioned one interesting thing more.
When I switch to another task, in case of a lost mouse click - not only keyboard works correctly in the active window, but mouse scroll works correctly too. Only mouse clicks (left and right buttons, additional buttons too) are lost for the first click. So, for example, if I switch to another window using mouse and WinList - I cannot use WinList again immediately, the first click of additional button is lost, WinList does not get active.

I confirm that this commit solved the problem.
Thanks a lot, raster!