- Improve default performance when components check if they are opaque
- Allows all components to take advantage of setPaintingIsUnclipped
- Give more control to opt out of opaque checks separate from setPaintingIsUnclipped
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.
The old implementation had a few problems:
- For a target area near but not touching the bottom of the parent area,
and a long menu with an initially-visible item halfway through the
list, the initially-visible item would sometimes be obscured by the
scroller area. The new implementation adjusts the size of the menu to
ensure that there's enough additional room for the scroller areas.
- For a target area at the very top or very bottom of the target area,
the menu would be positioned inconsistently; sometimes it would
overlap with the target area, but other times it would be positioned
with a gap separating the menu and target area. In the new
implementation, if there's not enough room for scrollers to be
positioned above/below the target area, the menu will always be
positioned so that it touches but does not overlap the target area.
- The initially-selected item would normally be
positioned as close as possible to the target area, but this wasn't
always applied consistently for long menus, and the menu would
sometimes only be scrolled enough to make the item visible at the end
of the menu furthest from the target area. In the new implementation,
the initially-visible item will always be positioned on top of the
target area, or adjacent to it, depending on the available space.
This makes it a bit easier to see exactly which PopupMenu state is used
during the calculation, and enforces that no menu state is modified
during the call.
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.
