* Make dart wrappable classes use only one native field
It appears like the second native field is never really used for
anything: It is set, cleared and verified it was cleared, but that is
it.
=> The only native field that is necessary is the `this` pointer of the
equivalent C++ object.
=> The [DartWrapperInfo] object which was stored as second native field
is always accessible via the virtual `GetDartWrapperInfo()` method on
`this`.
This lookup is implicit in GN. Explicitly specifying the glfw in
//build/secondary makes GN think multiple sources generate the same
intermediate object file.
This used to work because no other target also includes glfw. But I
am changing that in an upcoming test harness.
Fixes an issue where pressing AltGr key (on supporting layouts such as Spanish) on Windows causes CtrlLeft to hang pressed for both Flutter and Windows.
Co-authored-by: Greg Spencer <gspencergoog@users.noreply.github.com>
Adds support for running the dart runner as a CFv2 component.
The runner has been refactored to launch in both a v1 environemnt
as well as a v2 environment.
* 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
