Bug 351382 - telegram-desktop loses focus when choosing an option from a right-click menu
Summary: telegram-desktop loses focus when choosing an option from a right-click menu
Status: RESOLVED WORKSFORME
Alias: None
Product: kwin
Classification: Plasma
Component: rules (other bugs)
Version First Reported In: 5.3.2
Platform: Compiled Sources Linux
: NOR normal
Target Milestone: ---
Assignee: KWin default assignee
URL:
Keywords: triaged
Depends on:
Blocks:
 
Reported: 2015-08-17 03:46 UTC by Jeff Bai
Modified: 2018-10-27 02:22 UTC (History)
1 user (show)

See Also:
Latest Commit:
Version Fixed/Implemented In:
Sentry Crash Report:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jeff Bai 2015-08-17 03:46:35 UTC
When using telegram-desktop application (official, version 0.8.50) in Plasma 5.3.2, with ibus (using ibus-qt but not kimpanel), if I right-click on any messages on the chat window, the telegram-desktop window will lose focus. However, when I chose "Reply" (or anything really) on the right-click menu, the window will remain unfocused.

This has led to a problem that I won't be able to input anything with ibus before I click on the window to refocus it.

Reproducible: Always

Steps to Reproduce:
1. Start Plasma 5.3.2
2. Start telegram-desktop application
3. Choose a contact to chat with, input message with ibus (if using Chinese or anything like that)
4. Right click on any message
5. Choose "Reply"
6. Attempt to type in the input box

Actual Results:  
Telegram window was not focused when chosen "Reply" from the menu, ibus will not find the window, or the input box, therefore not able to input Chinese (in my case, or Japaneses or any language that ibus supports).

Expected Results:  
Telegram window should be re-focused when chosen "Reply" from the menu, and one should be able to input from ibus.

Using the following IM interface variables.

export GTK_IM_MODULE=ibus
export QT_IM_MODULE=ibus
export XMODIFIERS=@im=ibus

ibus works fine with any KF5, K4, Qt5, Qt4, GTK+2/3 applications (everything).
Comment 1 Jeff Bai 2015-08-17 03:48:26 UTC
Additional comments may be found from here.

https://github.com/telegramdesktop/tdesktop/pull/759

That with other window managers, like mutter and openbox, the window will re-focus after choosing from the right-click menu.
Comment 2 Martin Flöser 2015-08-17 06:02:20 UTC
This seems to be more a problem of either telegram or ibus. Telegram should never lose focus in the first place. It sounds like focus is passed to another window (I assume ibus). That should not be: if ibus were not to try getting focus, telegram would not lose focus.

Unfortunately I do not know how the ibus architecture works and don't have it installed, so I cannot try to reproduce.

@Eike: can you perhaps enlighten me a little bit?
Comment 3 Thomas Lübking 2015-08-17 08:13:07 UTC
run "kcmshell5 kwinoptions"  and set the focus stealing prevention to "none"  => still a problem?

I assume telegram tries to play window manager on non override_redirect popups here and "forgets" to forcefully pass the focus around (where it should not play WM itfp, in case it does)
Comment 4 Eike Hein 2015-09-01 11:11:32 UTC
I don't think this is related to ibus in any way, from how I read the report there is no ibus window in play. The problem is that picking Reply doesn't move focus to the window with the input box.
Comment 5 Martin Flöser 2015-09-01 11:15:45 UTC
>  The problem is that picking Reply doesn't move focus to the window with the input box.

so that's a bug in telegram?
Comment 6 Thomas Lübking 2015-09-01 11:24:25 UTC
errhemmm:
> Telegram window should be re-focused when chosen "Reply" from the menu
> with other window managers, like mutter and openbox, the window will re-focus after choosing from the right-click menu.

$1 on FSP ./. buggy wannabewmandpassaroundfocus client, see AND ANSWER comment #3
Maybe the ibus thing pollutes class hints (to fail the FSP in-group permissions)
Comment 7 Eike Hein 2015-09-01 11:38:49 UTC
ibus doesn't really get involved before the input field has focus.
Comment 8 Andrew Crouthamel 2018-09-25 21:36:56 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 15 days. Please provide the requested information as soon as possible and set the bug status as REPORTED. Due to regular bug tracker maintenance, if the bug is still in NEEDSINFO status with no change in 30 days, the bug will be closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

If you have already provided the requested information, please set the bug status as REPORTED so that the KDE team knows that the bug is ready to be confirmed.

Thank you for helping us make KDE software even better for everyone!
Comment 9 Andrew Crouthamel 2018-10-27 02:22:20 UTC
Dear Bug Submitter,

This bug has been in NEEDSINFO status with no change for at least 30 days. The bug is now closed as RESOLVED > WORKSFORME due to lack of needed information.

For more information about our bug triaging procedures please read the wiki located here: https://community.kde.org/Guidelines_and_HOWTOs/Bug_triaging

Thank you for helping us make KDE software even better for everyone!