Chrome Trace viewer treats events labeled "VSYNC" as special and highlights them (when the "Highlight Vsync" checkbox is enabled). Ideally VSYNC events are generated by the host system at their source. System VSYNC events are indeed present in full-system systraces. Flutter-level traces (as seen in Observatory/Flutter devtools) do not contain the system VSYNC events, so we rely on the engine to generate them (as close to where they would be generated by the system ideally).
Flutter crash reports on Fuchsia are considered non-fatal because they're not filed in response to the termination of the Flutter application, just a Dart exception that was thrown.
* Remove IAccessible and IChromeAccessible from AXPlatformNodeWin
* Fixes to make AXPlatformNodeWin, AXFragmentRootWin and associated unit
tests work and pass in Flutter/Windows
This updates Flutter.*Codec `decode:` implementations to treat empty
messages as equivalent to nil or NSNull, which avoids a crash when we
subsequently otherwise try to read the type/value from the message. This
handles the case where the sender were to send `null` over the channel.
e.g.,
final channel = BasicMessageChannel<Object?>('somechannel', StandardMessageCodec());
channel.send(null);
It also updates the macOS embedder to send nil to the decoder when a
zero-length message is received in order to be consistent with the iOS
embedding.
Previously, the macOS embedder always encoded platform messages as
NSData regardless of length:
ca1a7760b4/shell/platform/darwin/macos/framework/Source/FlutterEngine.mm (L498-L500)
The iOS embedder did not have this issue since it special-cased
zero-length messages as nil:
ca1a7760b4/shell/platform/darwin/ios/framework/Source/platform_message_router.mm (L23-L26)
Bug: https://github.com/flutter/flutter/issues/78003
The EGL context will be used by other threads during test execution, and it
should not be active on multiple threads at the same time. This was not
noticed previously because SwiftShader was not checking for this, but other
EGL implementations may enforce this constraint.
While we no longer crash when the framebuffer destruction_callback is
null (patched in https://github.com/flutter/engine/pull/24845) we should
bet setting one, even if it's a no-op containing a comment pointing to
where cleanup is implemented.
In MakeSkSurfaceFromBackingStore and other places in embedder.cc, we
call a texture or framebuffer destruction callback without first
verifying it's non-null. This adds a check before such calls.
Currently fl_renderer_gl_create_backing_store() in the Linux GTK
embedder and ExternalTextureGL::PopulateTexture() in the Windows
embedder either explicitly or implicitly set a null destruction
callback.
This prevents a crash reported when running under OpenGL ES 2.0 reported
in https://github.com/flutter/flutter/issues/76881.
While this prevents the crash, it does not fix the underlying issue.
Corrects uses of setup as a verb to 'set up', leaves noun/noun-phrase
forms of setup as 'setup'. Also settles on 'teardown' as opposed to
tear-down for consistency across the codebase.
A few other minor comment/wording corrections.
This moves tooling related to the creation of the Android embedding
bundle CIPD package under tools/cipd. Having a single location for CIPD
package creation tooling avoids spreading these around the tree and aids
in discovery.
This does not change the path within the CIPD package repo, nor does it
change the path to which we download it via gclient as specified in the
DEPS file.
This will be followed by a patch to add a new Windows CIPD package
necessary for UWP builds.
This change fixes a bug in Korean input whereby WM_IME_COMPOSITION
messages of type GCS_RESULTSTR were assumed to end composing mode.
This change breaks out an additional handler for "commit composing text"
events. In Japanese/Chinese IMEs, these events typically occur on
selection of a candidate from the candidates list and are mostly
synonymous with an "end composing" event.
In Korean text input, there is no candidates list, but rather a
character is built up as keypresses are handled, and committed as soon
as the character is unambiguously complete; in other words, when either
space/return is pressed or a keypress is received that cannot be
interpreted as a modification of the character being composed and
therefore must be the first keystroke of a new character. In these
cases, we want to commit the previous character without ending the
composition.
To illustrate with an example:
1. User focuses on a text field and sets input mode to Hangul.
2. User presses 'ㄱ'. Composing region contains 'ㄱ'.
3. User presses 'ㅏ'. Composing region is updated to '가'.
4. User presses 'ㄴ'. Composing region is updated to '간'.
5. User presses 'ㅏ'. Result string '가' is committed. Composing region is
updated to '나'.
6. User presses 'ㄷ'. Composing string is updated to '낟'.
7. User presses 'ㅏ'. Result string '나' is committed. Composing region is
updated to '다'.
8. User presses space or enter. Result string '다' is committed.
Composing is ended.
On a non-Korean QWERTY keyboard the following key mappings serve to
perform the above input:
* r -> ㄱ
* k -> ㅏ
* s -> ㄴ
* e -> ㄷ
To support the above, we break out a separate "commit composing" method
and commit on WM_IME_COMPOSITION events of type GCS_RESULTSTR and end
composing on WM_IME_ENDCOMPOSITION events. Further, we eliminate the
workaround in the GCS_RESULTSTR handler for continued composition on
Chinese/Japanese IMEs now that we're no longer ending composition on
that event type.
