GObject's dispose() method may be called multiple times. Guard against
trying to disconnect the same signal multiple times by clearing the ID
to avoid warnings when closing the window.
```
(bug:74019): GLib-GObject-WARNING **: 11:15:08.697: ../../../gobject/gsignal.c:2731: instance '0x55e1c3ea0200' has no handler with id '255'
```
* Recognize high contrast theme switch
* Trigger high contrast mode based on OS
* Confirm updated status and flag via unit test
* Remove null check, format
* Formatting
* More formatting
* Import order
* Refactor for PR
* Formatting
* Rename Update to Send
* Remove queued flags
* Add OnThemeChange unit test
* Format for linux_unopt
* Remove unneeded expect
* Test SendInitialAccessibilityFeatures
* Keep null check to embedder
This crash has come up a number of times and we tend to
burn time looking in the wrong places for the fix. Documenting
some stuff about how we've fixed it previously in the error
message.
* Include checkbox in check state update
* Windows test for checkbox native state
* Reformat to appease linux_unopt test
* More format hoops
* Update accessibility_bridge_unittests.cc
* Update flutter_windows_view_unittests.cc
When setting FlutterProjectArgs.command_line_argv prior to launching the
engine, we were previously setting a placeholder value rather than the
executable name. This resulted in Platform.executable (from dart:io)
returning "placeholder" in application code.
This updates the Windows implementation for consistency with macOS and
guarantees that Platform.executable will return a reasonable value in
Dart code.
Note that this does not affect Platform.resolvedExecutable, which returns
a full, resolved path, and is implemented in the Dart runtime itself.
Previously the code:
print(Platform.executable);
print(Platform.resolvedExecutable);
resulted in the following output on Windows:
flutter: placeholder
flutter: C:\path\to\project\build\windows\runner\Debug\project.exe
after this patch, it results in:
flutter: project.exe
flutter: C:\path\to\project\build\windows\runner\Debug\project.exe
Issue: https://github.com/flutter/flutter/issues/83921
Update Picture rasterization for toImage to accept a layer tree, optionally flattening on the raster thread if present.
Update Deferred GPU image for toImageSync to accept a layer tree, flattening it the first time it creates an image, storing the resulting display list.
This is also a performance fix for the zoom page transition, which currently does too much work on the UI thread on frame 1
Migrates error logging from logging directly to stderr to using the
FML_LOG macro with a specified log level.
No additional tests since there is no semantic change to the logging
(FML_LOG simply writes to stderr).
Adds the ability to register native functions for use in test fixtures.
This allows registering native C++ functions that can be invoked from
Dart code to perform the following common actions:
* Signal a waiting latch in the C++ part of the test.
* Pass data back to the C++ part of the test.
* Allow the C++ part of the test to pass data to the test.
Fixes: https://github.com/flutter/flutter/issues/109242
Fixes: https://github.com/flutter/flutter/issues/87299
channel closure.
This CL resets the state including cleaning up the buffers whenever
a fuchsia.ui.pointerinjector.Device channel closes due to some error.
Test: flutter_runner_tests
Eliminate a few uses of memset in the code, replacing them with C++
alternatives, like using initialiser list syntax and std::array + fill.
This avoids some double-hardcoding of array length in the code.
This adds a dart_entrypoint field to FlutterDesktopEngineProperties in
the public C Windows API, which mirrors that in the embedder API.
When a null or empty entrypoint is specified, a default entrypoint of
'main' is assumed. Otherwise, the app is launched at the top-level
function specified, which must be annotated with
@pragma('vm:entry-point') in the Dart source.
This change is backward-compatible for existing users of the Windows C API
and the C++ client wrapper API. To avoid breaking backward compatibility,
this patch preserves the entry_point parameter to FlutterDesktopEngineRun
in the public Windows C API as well as in the FlutterEngine::Run method
in the C++ client wrapper API. The entrypoint can be specified in either
the engine properties struct or via the parameter, but if conflicting
non-empty values are specified, the engine launch will intentionally fail
with an error message.
This change has no effect on existing Flutter Windows desktop apps and no
migration is required, because our app templates never specify a custom
entrypoint, nor was the option to specify one via the old method particularly
feasible, because the FlutterViewController class constructor immediately
invokes FlutterViewControllerCreate which immediately launches the engine
passed to it with a null entrypoint argument, so long as the engine is not
already running. However, running the engine without a view controller
previously resulted in errors due to failure to create a rendering surface.
This is a followup patch to https://github.com/flutter/engine/pull/35273
which added support for running Dart fixture tests with a live Windows
embedder engine.
Fixes: https://github.com/flutter/flutter/issues/93537
Related: https://github.com/flutter/flutter/issues/87299
Adds a new header, flutter_macros.h which includes a FLUTTER_DEPRECATED
macro that can be used to mark deprecated API as such, with a
hopefully-informative message, ideally describing the expected removal
version and any migration tips.
This will need to be #included in flutter_windows.h and flutter_linux.h,
but prior to doing so, we'll need to update the engine recipe to bundle
the new header, here:
https://flutter.googlesource.com/recipes/+/refs/heads/main/recipes/engine/engine.py#1457
No tests since this adds a compiler macro that will be used for future
C/C++ API deprecation once the above recipe change has landed;
specifically: FlutterDesktopEngineProcessMessages.
Related: https://github.com/flutter/flutter/issues/93537
Fixes a minor whitespace inconsistency on the documentation for
FLUTTER_EXPORT.
No test change since there is no change to code semantics.
Related: https://github.com/flutter/flutter/issues/93537
This PR takes a step back and changes the GTK IM client window back from FlView to GtkApplicationWindow as it was before #33111. The window was originally changed to FlView to make the code testable by cutting a dependency to gtk_widget_translate_coordinates(). The change was hard to revert because there were several conflicting changes on top. Therefore, this PR introduces an FlTextInputViewDelegate to be able to provide coordinate mapping in a testable way.
Fixes: flutter/flutter#108832
This adds support for running end-to-end tests that use a live engine to
run Dart test fixtures. This enables testing the public Windows C API in
//flutter/shell/platform/windows/public/flutter_windows.h
This only adds support for a single test entrypoint (main). A followup
patch will add support for this. See:
https://github.com/flutter/flutter/issues/93537
Issue: https://github.com/flutter/flutter/issues/87299
All Flutter engines in the same process share a common Dart VM, which is
launched with the start of the first engine in the process and should be
terminated when the last engine in the process has been deallocated.
Formerly, it was not possible to cleanly shut down and restart the VM in
a process, but this was resolved in the Dart SDK and a flag exposed in
flutter/engine#10652. Since some embedders take advantage of the fact
that the VM remains running after engine shutdown, this flag is not
enabled by default, however it should be enabled for the Windows
embedder, which we control.
No tests added since this is not testable via any API to which the
Windows embedder has access. The behaviour of this flag is tested in the
embedder API tests in `EmbedderTest.VMShutsDownWhenNoEnginesInProcess`
in shell/platform/embedder/tests/embedder_unittests.cc.
Issue: https://github.com/flutter/flutter/issues/109191
In flutter/engine#35106, I landed a parameter type fix for the
declaration of FlutterDesktopEngineGetTextureRegistrar in our public
Windows C API. I also added a unit test that called this function.
That function (and all others) in our public Windows API is marked
FLUTTER_EXPORT, which resolves to __declspec(dllexport) or
__declspec(dllimport) depending on whether FLUTTER_DESKTOP_LIBRARY is
defined. It can be defined by adding the following build config:
//flutter/shell/platform/common:desktop_library_implementation
If the function is marked as an import, we get linker warnings that
we're importing a function that's defined in the same executable image.
This patch resolves this by marking the functions as export.
An alternative fix would be to support a third macro resolution that
resolves to nothing in the presence of some definition like
FLUTTER_NO_EXPORT; however, since flutter_export.h is a public header,
I'd prefer not to complicate it further, and this is a unit test that
can't be linked against either way.
Issue: https://github.com/flutter/flutter/issues/109184
Original issue: https://github.com/flutter/flutter/issues/86617
See: https://github.com/flutter/engine/blob/main/shell/platform/common/public/flutter_export.h
See: 61c0051a63/shell/platform/common/BUILD.gn (L8-L10)
No new tests since this simply fixes a link warning message in unit tests.
