Assigned
Status Update
Comments
se...@google.com <se...@google.com> #2
I have the same issue. The floating toolbar keeps on stealing the focus. You can mouse click on text area but keyboard input wont work. Sometimes i can get the emulator to get the focus but it is so random. Sometimes clocing both left and mouse button on the emulator would fix it.
OS:
Xubuntu 15.10
OS:
Xubuntu 15.10
po...@gmail.com <po...@gmail.com> #3
I have the same issue.
Clicking on the window title bar of the "device window" does not move the focus to the device but to the control button toolbar. I am unable to move the focus to the device via any other means (task bar or Alt-Tab etc.).
The workaround described by remcohaszing works, but I have to do this everytime after the device lost the focus, which is quite often, when developing.
So it's a real show stopper for me.
The only practical workaround I found is to set "focus on mouse over" instead of "focus on click" (which I don't like otherwise).
But even in this mode, when I move the mouse over the title bar (not the window contents) for the first time after the device lost it's focus by a *click* on another window, the toolbar gets the focus instead.
It works when I move the mouse to the title bar a second time *and* as long as I do not *click* somewhere outside the device window. Tabbing away is also like clicking.
So where is the difference between loosing the focus by click or tab against moveing the mouse?
My system is a current debian testing/unstable mix using xfce4 with xfwm4.
Clicking on the window title bar of the "device window" does not move the focus to the device but to the control button toolbar. I am unable to move the focus to the device via any other means (task bar or Alt-Tab etc.).
The workaround described by remcohaszing works, but I have to do this everytime after the device lost the focus, which is quite often, when developing.
So it's a real show stopper for me.
The only practical workaround I found is to set "focus on mouse over" instead of "focus on click" (which I don't like otherwise).
But even in this mode, when I move the mouse over the title bar (not the window contents) for the first time after the device lost it's focus by a *click* on another window, the toolbar gets the focus instead.
It works when I move the mouse to the title bar a second time *and* as long as I do not *click* somewhere outside the device window. Tabbing away is also like clicking.
So where is the difference between loosing the focus by click or tab against moveing the mouse?
My system is a current debian testing/unstable mix using xfce4 with xfwm4.
se...@google.com <se...@google.com> #4
I have narrowed the issue to using xfwm4 (I usually use 4.12.x and also tried 4.10.x).
I changed any corresponding options like "focus stealing prevention" and "honour ICCCM focus hint" and even disabled compositing, but all this doesn't matter.
I then tried several alternate window managers and they all worked including clicking, tabbing etc.:
openbox
fluxbox
jwm
lwm
I still don't blame xfwm4 alone, because I never ever had any other focus issue with xfwm4 since several generations. So I believe it's a combination of emulator's behaviour *and* xfwm4's behaviour.
Another hint: when I click on the avd and then on another window e.g. a shell window and then close this focused window, the emulator device gets the focus.
I changed any corresponding options like "focus stealing prevention" and "honour ICCCM focus hint" and even disabled compositing, but all this doesn't matter.
I then tried several alternate window managers and they all worked including clicking, tabbing etc.:
openbox
fluxbox
jwm
lwm
I still don't blame xfwm4 alone, because I never ever had any other focus issue with xfwm4 since several generations. So I believe it's a combination of emulator's behaviour *and* xfwm4's behaviour.
Another hint: when I click on the avd and then on another window e.g. a shell window and then close this focused window, the emulator device gets the focus.
se...@google.com <se...@google.com> #5
... so a simple launcher like "xterm -e exit" allows to give the focus back to the emulator device.
While testing window managers etc. I somehow managed to get rid of the control buttons toolbar window (may be it was on another workspace, or closed by someone). Then the device window worked well apart from the missing buttons.
I also tried with wmctrl:
wmctrl -i -a 0x06200003
wmctrl -i -R 0x06200003
with the hex number being the Android Emulator window (=device)
both remove the focus from my shell window, but the device window doesn't get it
(as usual the button bar gets the focus)
t=0.1; w=0x06200003; for s in modal sticky maximized_vert maximized_horz skip_taskbar skip_pager hidden fullscreen above below; do echo $s; wmctrl -i -r $w -b toggle,$s; sleep $t; wmctrl -i -a $w; sleep $t; wmctrl -i -r $w -b toggle,$s; sleep $t; wmctrl -i -a $w; sleep $t; done
doesn't move focus to the device
but...
t=0.0; t2=0.5; w=0x06200003; s=shaded; echo $s; while true; do wmctrl -i -r $w -b remove,$s; sleep $t; wmctrl -i -a $w; sleep $t; sleep $t2; wmctrl -i -r $w -b add,$s; sleep $t2; wmctrl -i -a $w; sleep $t; wmctrl -i -r $w -b remove,$s; sleep 3; done
moves the focus to the device every other time
Generally the focus works, when the device window is in shaded mode ("rolled up").
This even works when selecting the mode via window menu and then clicking on the title or on the task bar entry.
In this mode the toolbar doesn't come to front either.
While testing window managers etc. I somehow managed to get rid of the control buttons toolbar window (may be it was on another workspace, or closed by someone). Then the device window worked well apart from the missing buttons.
I also tried with wmctrl:
wmctrl -i -a 0x06200003
wmctrl -i -R 0x06200003
with the hex number being the Android Emulator window (=device)
both remove the focus from my shell window, but the device window doesn't get it
(as usual the button bar gets the focus)
t=0.1; w=0x06200003; for s in modal sticky maximized_vert maximized_horz skip_taskbar skip_pager hidden fullscreen above below; do echo $s; wmctrl -i -r $w -b toggle,$s; sleep $t; wmctrl -i -a $w; sleep $t; wmctrl -i -r $w -b toggle,$s; sleep $t; wmctrl -i -a $w; sleep $t; done
doesn't move focus to the device
but...
t=0.0; t2=0.5; w=0x06200003; s=shaded; echo $s; while true; do wmctrl -i -r $w -b remove,$s; sleep $t; wmctrl -i -a $w; sleep $t; sleep $t2; wmctrl -i -r $w -b add,$s; sleep $t2; wmctrl -i -a $w; sleep $t; wmctrl -i -r $w -b remove,$s; sleep 3; done
moves the focus to the device every other time
Generally the focus works, when the device window is in shaded mode ("rolled up").
This even works when selecting the mode via window menu and then clicking on the title or on the task bar entry.
In this mode the toolbar doesn't come to front either.
se...@google.com <se...@google.com> #6
if the device window has the focus and it's moved via mouse and title bar, it looses focus.
Over all, something like a setFocus-event seems to be used to explicitly set the focus to the toolbar.
Thinking about that, it seems to be a conflict situation.
Some keys should go to the toolbar and some should go to the device.
I think, the natural way to handle that would be:
the toolbar gets all keys (so it has the focus all the time).
Keys not used by the toolbar should then be forwarded to the device window.
I also don't really understand, why there are two windows which are strictly glued together. Two windows would make sense, if they can be moved independently (at least sometimes) or may be the offset would be adjustable. But when I move the toolbar by Alt-Mouse window movement, it always jumps back to the device window when I move that.
Over all, something like a setFocus-event seems to be used to explicitly set the focus to the toolbar.
Thinking about that, it seems to be a conflict situation.
Some keys should go to the toolbar and some should go to the device.
I think, the natural way to handle that would be:
the toolbar gets all keys (so it has the focus all the time).
Keys not used by the toolbar should then be forwarded to the device window.
I also don't really understand, why there are two windows which are strictly glued together. Two windows would make sense, if they can be moved independently (at least sometimes) or may be the offset would be adjustable. But when I move the toolbar by Alt-Mouse window movement, it always jumps back to the device window when I move that.
se...@google.com <se...@google.com> #7
btw. my emulator version is 25.2.2-3098464 (Stable update channel)
is there a newer version for testing?
is there a newer version for testing?
po...@gmail.com <po...@gmail.com> #8
For those facing this, it is relatively easy to substitute Metacity for xfwm4 as the window manager for Xfce4 (on Debian): download the metacity package, and run "metacity --replace". The emulator keyboard immediately works again. However, it's not a satisfactory fix: window manager xfwm4 UI tools stop working, window behavior is slightly different (e.g. snap behavior), and for me, XRDP broke. Pity to have to deal with all this because of what may be a relatively minor bug. Please consider fixing soon. Thanks in advance.
se...@google.com <se...@google.com> #9
Xubuntu is using an unsupported windows & desktop manager...we can look into the issue, but by default, we test and support Ubuntu running GNOME or KDE.
Description
Jetpack Compose version: 1.7.6
Jetpack Compose component used:
Android Studio Build: Ladybug Feature Drop 2024.2.2
Kotlin version: 2.1.0
Devices/Android versions reproduced on: Phone Emulator (API 34)
Keyboard (i.e. Gboard, Samsung, etc): AOSP Keyboard
If you have Material text
inside the layout with
Modifier.imePadding()
applied to it, and trigger the appearance of the soft keyboard, then text starts to move to the right of the screen.This bug is very similar to this one and is probably related to this code (it was introduced here ).
Screenshots and video attached.