* Move task_observers.{cc,h} into fml.
This is a preparatory CL. The next CL will cause task_observers.h to
be included from both shell/platform/fuchsia _and_
fml/platform/fuchsia. I imagine it might be gauche for a single file
to be used from both those directories, but it seems way worse for fml
to depend on shell, rather than the other way around.
* Replace flutter_runner::Thread with fml::Thread.
This CL makes the treading logic in Fuchsia's flutter_runner more
consistent with fml expectations, but it still has quirks. Notably:
- Not all async work get posted to a fml::TaskRunner. Some work done
by Fuchsia libraries gets posted directly to
async_get_default_dispatcher(). This work doesn't trigger the
fml::MessageLoop's task observers. As a result, we continue to have
Fuchsia-specific task observers which fire for all async work,
regardless of which way it was posted.
- There's awkwardness when trying to run Fuchsia code on a specific
fml::TaskRunner if that fuchsia code accepts an
async_dispatcher_t. Since you can no longer get an
async_dispatcher_t for a given thread, you instead must post a
closure to the fml::TaskRunner that calls
async_get_default_dispatcher(), and then calls the fuchsia library
with the default dispatcher.
- Some tests still use task_runner_adapter.h because async::Loop
offers more control in unit tests than fml::MessageLoop does.
- If this successfully lands, there will be some cosmetic follow-up
changes to make, like using ThreadHost instead of an array of
fml::Threads.
* Increase stack size in flutter runner.
The previous change removes our custom 1MiB limit on the stack of
newly created threads, so these threads revert to the Fuchsia
default. google-internal tests were failing (without any particular
error in the logs) after this change, so here we just set the default
stack size to 1MiB.
Co-authored-by: Hunter Freyer <hjfreyer@google.com>
Switch from `fml::NonOwnedMapping` to `fml::DataMapping`.
All other uses of `fml::NonOwnedMapping` are not in `PlatformView` and do not access data after references are out of scope.
This fixes https://fxbug.dev/77924.
Functions/methods registered in `platform_message_handlers_` should return true or false, indicating whether the response was handled by them.
This makes it more explicit whether a platform message handler will asynchronously complete a response, versus if there was malformed/invalid request.
If the response was not handled, `CompleteEmpty` in `PlatformView::HandlePlatformMessage` to avoid hanging `Future`s in dart.
This fixes https://fxbug.dev/79056.
Context creation options for each backend were spread across multiple
translation units. This makes setting options common across all backends hard to
configure. I have moved the creation of such common options into a separate
translation unit.
Fixes https://github.com/flutter/flutter/issues/84213
Passing the --causal-async-stacks flag to the VM will cause it to error
on VM startup. The VM will remove the flag entirely, but before doing so
we'll have to remove usages of the negated version of the flag, namely
--no-causal-async-stacks.
This option will be the default in Skia soon. Per discussion in #26067, let’s be explicit about disabling it for the time being, and we can revisit the flag in the future if desirable.
TextInputType.none makes it possible to disable the virtual keyboard
for certain TextFields, and lays the foundations for custom in-app
virtual keyboards (flutter/flutter#76072).
Ref: flutter/flutter#83567
