Prior to this fix calling setDirectory and then setSelectedFile from the
same call stack could cause setSelectedFile to have no effect. This was
because the directory change is asynchronously propagated from the
DirectoryContentsList. This was picked up by the FileListComponent as a
directory change after setSelectedFile, even though the directory change
happened before.
Before 2c5b1fbb6f, we only queried
currentlyFocusedPeer during runAsync(), instead of reading it
immediately. The behaviour after that commit prevented message boxes
from showing if showMessageBoxAsync() was called before any peer had
been created.
With the PopupMenu creating its own window the focus would return to the
ComboBox after activating a menu item. Prior to this commit however the
focus was seemingly lost after menu item activation. With this change
the focus returns to the ComboBox in both cases.
The issue became manifest in c51b331318.
In our implementation the toggle action takes precedence over the press
action, making the latter unreachable when the Item is in a checkable
state. Calling isTicked (true) turns the Item into a checkable object.
The onToggle implementation however didn't interact with the isTicked
state, and it didn't fire the press action either. This made the item
non-interactable with screen readers once it got into a ticked state.
This bug could be observed in the DemoRunner:
- Enable "button" navigation mode (as opposed to "gesture" mode) on the
Android device.
- Remove the line enabling kiosk mode, build and install the DemoRunner.
- Run the app and navigate to the Settings pane. Open a menu, or the
bluetooth MIDI dialog window, then close the popup window.
- Rotate the device.
Previously, the steps above could result in the system painting its own
backgrounds behind the system bars. With this patch in place, we reset
the requested system UI colours and transparency, which seems to
maintain the desired appearance.
A recent change made disabled components traversable by default when
using a screen reader. This change makes TalkBack report such components
as disabled.
With this change disabled components become discoverable by screen
readers, similarly to how OS native user interface components behave by
default.
The KeyboardFocusTraverser will still skip disabled components so this
does not affect keyboard navigation without screen readers.
handlePositionChanged() is called when the window changes z-order, which
may cause a new mouse event to be synthesised if the mouse is over the
window after the z-order is updated. In this situation, we may not have
received a mouse up/down/move event to update the current modifier
flags, so we need to update them ourselves.
This reimplements similar functionality to that removed in
d39789b021.
Unlike the previous implementation, this version will still wait for the
mouse to move over the menu before the countdown timer is allowed to
start. This should avoid the situation where menu items are accidentally
triggered on mouse-up, after a menu opens under the pointer in response
to a mouse-down.
ComponentPeer::setAppStyle() will now update the status and navigation
bar foreground colours, with some caveats:
- Status and nav bar backgrounds are now always completely transparent.
- The navigation bar foreground colour can only be changed on Android
API 26 or higher.
- For platforms using gesture controls instead of button controls, the
system automatically determines the colour of the gesture bar. On
those systems, setAppStyle() will only affect the status bar colour.
This is a different approach to the change introduced in
04f87320d5.
Instead of completely recreating the window, we now just update the
window's style flags. This should ensure that window and component focus
are preserved.
This follows on from the work in
3e70c37ce3.
The previous patch had the intended effect as long as the peer was
recreated after entering kiosk mode. However, for windows initially
created with non-native titlebars, attempting to disable the titlebar
would have no effect.
We now check whether the native style flags would need to change as a
result of changing kiosk mode, and recreate the peer if necessary.
467f20a7a1 introduced a change to start processing WM_NCMOUSELEAVE
messages as mouse-exit events. This behaviour is not quite correct,
because NCMOUSELEAVE may be triggered when moving the cursor from the
nonclient area to the client area, in which case the mouse is still over
the window.
We now check whether the mouse is really over the window inside
doMouseExit(), and continue to track it if necessary.
