The initial implementation tried to leverage the fuchsia.git approach to
adding resources via GN template, but the GN SDK does not use the same
format or approach. This PR adds the snapshot resource in the way the
GN SDK expects.
The integration test works in debug/jit mode only, and building in
`profile` and `release` modes was not working, breaking some builders.
The workaround was to disable the test.
This PR will enable release/aot mode so it will build, and unblock both
the debug-mode version of the test (tested by CI) and release mode
builds of the repo.
Due to the request to unblock, this PR does not yet build packages in
`profile` mode that will run in Fuchsia, but it should at least build
without errors. Ongoing work is in progress to also support running in
release mode.
* Add new channel updateEditingStateWithDelta
* Fix formatting
* Fix formatting
* Fix formatting
* Add equality case
* formatting
* Implement TextEditingDelta class to encapsulate delta logic
* Formatting
* Also send new composing/selection along with delta
* Utilize an ArrayList of TextEditingDeltas to take into account batch editing
* clear batch deltas when editing state is updated by framework, we don't want to collect deltas from the framework because they have already been applied to the value on the framework side
* fix formatting
* formatting
* formatting
* Add enableDeltaModel flag to choose between updateEditingValue and updateEditingValueWithDeltas
* Add autofill support for delta model
* formatting
* update
* Fix issues with composing region
* formatting
* Remove
* Fix out of bounds error when textfield is initialized with text
* Clean up logs
* formatting
* update licenses
* Fix deletion issues
* formatting
* delta -> deltaType
* updates
* formatting
* formatting
* Fix logs
* Add tests for TextEditingDelta
* formatting fixes
* remove unused imports
* Fix return type for getDeltaType
* Fix tests
* Fix ListenableEditingStateTest
* formatting
* Fix typo
* Add test for deltas when setComposingText
* formatting
* Updates to test
* fix typo
* formatting
* Verify all properties of delta for test
* formatting
* Add VisibleForTesting import
* fix test
* fix formatting
* fix tests
* fix tests
* fix tests
* updates for tests
* remove ide made file
* Fix more tests
* Fix TextEditingDelta tests
* Add test for verifying delta is generated on setComposingText
* Add TextInputPlugin tests for replacement and deletion deltas
* formatting
* formatting
* Capture delta on setSpan and clear deltas when generated from the framework and when we skip updating the framework
* fix formatting
* update tests to reflect new clear batch delta calls
* Make deletion inline with platform
* fix tests
* Address reviewer comments
* formatting
* fix tests
* fix tests
* move delta inference to framework
* update tests
* formatting
* fix tests
* Formatting
* get -> extract
* More tests and address reviewer comments
* clean up logs
* Address reviewer comments
* formatting
* formatting
* Remove testing constructor
* send as deltas
Bug: fxb/79871
The code is still using the CFv1 implementation, so this should not affect the existing behavior.
For this version of the PR, I forked the existing DartComponentController. There were a few reasons for this:
Reduces the chance of the change breaking existing tests during Fuchsia GI.
Makes the V2 version of the DartComponentController simpler to read.
Makes it easier to switch over to using the V2 version of the DartComponentController once the migration is ready to happen (less cleanup).
The rate of changes to the DartComponentController is slow so there shouldn't be much maintenance required for the fork.
Changes to the DartRunner itself will happen in a follow-up PR - this PR only verifies that the ComponentController builds.
Relands GN and C++ changes for #27226 after rollback in #28036.
The multiprocessing package relies on the win32 `WaitForMultipleObjects`
call, which supports waiting on a maximum of MAXIMUM_WAIT_OBJECTS
(defined by Windows to be 64) handles, processes in this case. To avoid
hitting this, we limit ourselves to 60 handles (since there are a couple
extra processes launched for the queue reader and thread wakeup reader).
When left unspecified, the multiprocessing module defaults this value to
os.cpu_count(), so this error is triggered only on machines with > 60
cores.
See: https://bugs.python.org/issue2690
Bug: https://github.com/flutter/flutter/issues/90085
Bug: 79871
Partial re-land of #27226 (which was reverted in #28036 due to a flaky test). Only adds in the CML files for a CFv2 dart_runner without the corresponding C++ and GN changes.
In the upcoming version of harfbuzz (3.0.0) the subsetting api is being declared stable. With this there are some changes to the API. This prepares flutter to start automatically using the new API once harfbuzz 3.0.0 is rolled into flutter.
This reverts commit 1e9b7aed566105eec982ca0eb545139b218bc916.
Reverting in order to land revert of the gn script_executable from
python3 to vpython3, which is causing flakes on Windows.
Issue: https://github.com/flutter/flutter/issues/88719
