This fixes an issue where the view would disappear and the window would
become black when the window scene changed, e.g. because screen sharing
was started.
This issue presented after the following sequence of steps:
- Display a window with a non-native titlebar
- Maximise it
- Click the taskbar icon to minimise it
- Click the taskbar icon again to maximise it
After being maximised for the second time, the window bounds were too
large for the display. This is because the check in WM_NCCALCSIZE was
failing to determine the target monitor for the window, and therefore
failing to adjust the new area appropriately. We now determine the
target monitor based on the proposed new bounds of the new window,
rather than the current bounds of the window, which may not be
meaningful if the window is minimised.
The important part seems to be initialising the UIWindow directly with
the UIWindowScene, instead of initialising it with a frame and then
assigning a scene later on.
On at least iOS 26 using a temporary window frame is unreliable. This
change tries to use an existing window for any non-standalone app. It
also updates the details on any changes, such as when the device
orientation changes.
This also fixes an issue where endBackgroundTask wasn't guaranteed to be
called after suspended() completed. According to the docs,
endBackgroundTask must be called after the task completes.
initWithWindowScene appears to create a window with no area if the
provided scene is null. As a fallback, creating a window without an
associated scene still returns usable bounds.
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.
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.
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.
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.
