* a11y: implement new SemanticsAction "showOnScreen" (v2)
This action is triggered when the user swipes (in accessibility mode) to the last visible item of a scrollable list to bring that item fully on screen.
This requires engine rolled to flutter/engine#3856.
I am in the process of adding tests, but I'd like to get early feedback to see if this approach is OK.
* fix null check
* review comments
* review comments
* Add test
* fix analyzer warning
* flutter analyze --watch auto detect if in flutter repo
* move isFlutterLibrary from AnalyzeOnce into AnalyzeBase for use by AnalyzeContinuously
* pass --flutter-repo to analysis server when analyzing the flutter repository
* enhance flutter analyze --watch to summarize public members lacking documentation
On Fuchsia, the system compositor is responsible for drawing shadows
for physical model layers with non-zero elevation.
Also fixed a bug where _needsCompositing was not being cleared prior
to updating it.
* Ensure that a frame is allways scheduled when a RenderObject marks itself as needing a semantics update
Fixes issue 2 described in https://github.com/flutter/flutter/issues/10971
Previously, an object could call `markNeedsSemanticsUpdate` and its wish would never be granted because no frame was scheduled that would actually update the semantics. This caused an issue during scrolling on Android where at the end of the scroll the `RenderIgnorePointer` would stop blocking the semantics of the scrolled view, call `markNeedsSemanticsUpdate`, but then no frame was scheduled to actually put the semantics of the scrolled view back into the semantics tree. That made the scrolled view unusable for a11y users.
At first I was a bit wary to call `requestVisualUpdate` within `markNeedsSemanticsUpdate` because technically the visual is fine, we only need the frame it schedules to update the semantics. However, it seems like we are using `requestVisualUpdate` for exactly that purpose in other places already where we just need an update to the semantics (e.g. 76a50fe0ca/packages/flutter/lib/src/rendering/object.dart (L2408)).
* add tests
In
df8bf384eb
a new functionality of the Dart VM Service Protocol has been introduced.
Clients connected to the Service Protocol are now able to expose
services that other clients (e.g. Observatory) can invoke through the
Service Protocol itself.
With these changes Flutter Tools register them self as a `reloadSources`
(a.k.a. HotReload) capable client.
Observatory is already listening for the clients which expose this
functionality and uses by default the service based version of
`reloadSources` when available, so requesting a HotReload from
Observatory will trigger the full Flutter HotReload.
Related https://github.com/dart-lang/sdk/issues/30023
Related https://github.com/flutter/flutter/pull/11229
Related https://github.com/flutter/flutter/pull/11256
In some cases, we've seen interactions between Instruments and the iOS
simulator that cause hung instruments and DTServiceHub processes. If
enough instances pile up, the host machine eventually becomes
unresponsive.
Until the underlying issue is resolved, manually kill any orphaned
instances (where the parent process has died and PPID is 1) before
launching another instruments run.
