Page MenuHomePhabricator

App popups on the luncher steal focus from windows
Closed, ResolvedPublic


To rep: click an app (ie terminology) on the luncher and don't move the mouse. the terminology window unfocuses.

ApB created this task.Mar 28 2018, 4:05 AM
zmike added a subscriber: bu5hm4n.Mar 28 2018, 6:48 AM

@bu5hm4n is there some specific unfocusable flag which would need to be set to prevent this? It's definitely new behavior...

Allow_focus to false

Hm based on this and the description of the ticket, it seems like the new behavior for widgets is to focus them upon becoming visible? If true then this seems undesirable for the majority of cases, as widget focus should only change when explicitly set/changed or if the currently-focused widget is no longer visible. At the least, this would definitely break existing applications which have relied upon the behavior that I described.

No - not on visibility. The special case here is due to the usage of elm_ctxpopup. When a elm_ctxpopup opens the popups content gets focus. Earlier this only happens for elm_widgets as content, now this also happens for normal evas objects, to make it consistent. If you dont want to have this behaviour, make elm_ctxpopup not allowing focus (if thats not working then i need to fix this).

To the point of break existing applications, i get a report of exactly the opposite, the behaviour was before like this, and i broke it due to the change that on elm_ctxpopup opening the content was not focused anymore.

I think the other report you received may be inaccurate? It should probably never be the case that widgets "grab" focus on their own.

No it was the same before, ctxpopup sets the focus explicitly.

Same for inwin, hover, notify.

Think for a second about it, you open a ctxpopup, background goes dark (thats the default), and you can still continue moving focus in the background ? that would be a bit weird.

And normally focus will be recovered to the last focused widget. However, e_client is not a widget, and thus its not recovered. but rather some elm_layout ...

zmike added a comment.Mar 29 2018, 7:19 AM

It depends. In the case of the default style, the reason focus would change is that everything under the ctxpopup is obscured. In the noblock style, which is what's used here, that is not the case and so it seems strange to me that focus would change.

Well, changing the behaviour of a widget depending on a style is even more weird ... and the obscured style is default, thus setting focus is the default action. And as I said, this has been like this before :)

zmike added a comment.Mar 29 2018, 9:27 AM

Apparently it has not been like this as there have been enlightenment releases shipping for years expecting a certain behavior and no longer achieving that behavior. Most likely whatever change is causing this should be modified to not apply to legacy objects.

Well, the only place where i can see the bug is in luncher, and luncher is how old ? a year ?
Take a checkout from a few years ago and you will see that focus is setted explictly on the content.
So NO! this has to apply to legacy objects as well as interface objects.
It was working before due to a bug. Sorry for that. But this now is the correct behaviour.

Can confirm that tree_focus_allow_set false is already being set on the ctxpopups on E's end and that this is indeed an EFL bug as we are not allowing or taking focus for the ctxpopups.