* Only creates 'onscreen_surface_' when it's not available in 'AndroidSurfaceGL::CreatePbufferSurface'
* Rename the function and add some unit tests
* Update android_surface_gl.h
Co-authored-by: Dan Field <dfield@gmail.com>
Fixes an issue with Korean IMEs wherein a text input state update may be
sent to the framework that misleads the framework into assuming that IME
composing has ended.
When inputting Korean text, characters are built up keystroke by
keystroke until the point that either:
* the user presses space/enter to terminate composing and commit the
character, or;
* the user presses a key such that the character currently being
composed cannot be modified further, and the IME determines that the
user has begun composing the next character.
The following is an example sequence of events for the latter case:
1. User presses ㅂ. GCS_COMPSTR event received with ㅂ. Embedder sends
state update to framework.
2. User presses ㅏ. GCS_COMPSTR event received with 바. Embedder sends
state update to framework.
3. User presses ㄴ. GCS_COMPSTR event received with 반. Embedder sends
state update to framework.
4. User presses ㅏ. At this point, the current character being composed
(반) cannot be modified in a meaningful way, and the IME determines
that the user is typing 바 followed by 나. GCS_RESULTSTR event
received with 바, immediately followed by GCS_COMPSTR event with 나.
In step 4, we previously sent two events to the framework, one
immediately after the other:
* GCS_RESULTSTR triggers the text input model to commit the current
composing region to the string under edit. This causes the composing
region to collapse to an empty range.
* GCS_COMPSTR triggers the text input model to insert the new composing
character and set the composing region to that character.
Conceptually, this is an atomic operation. The fourth keystroke causes
the 반 character to be broken into two (바 and ㄴ) and the latter to be
modified to 나. From the user's point of view, as well as from the IME's
point of view, the user has NOT stopped composing, and the composing
region has simply moved on to the next character.
Flutter has no concept of whether the user is composing or not other
that whether a non-empty composing region exists. As such, sending a
state update after the GCS_RESULTSTR event misleads the framework into
believing that composing has ended. This triggers a serious bug:
Text fields with input formatters applied do not perform input
formatting updates while composing is active; instead they wait until
composing has ended to apply any formatting. The previous behaviour
would thus trigger input formatters to be applied each time the user
input caused a new character to be input. This has the add-on negative
effect that once formatting has been applied, it sends an update back to
the embedder so that the native OS text input state can be updated.
However, since the GCS_RESULTSTR event is _immediately_ followed by a
GCS_COMPSTR, the state has changed in the meantime, and the embedder is
left processing an update (the intermediate state sent after the
GCS_RESULTSTR) which is now out of date (i.e. missing the new state from
the GCS_COMPSTR event).
Since GCS_RESULTR events are always immediately followed by a subsequent
GCS_COMPSTR (in the case where composing continues) or a
WM_IME_ENDCOMPOSITION (in the case where composing is finished), and
because the event handlers for both of those send updated state to the
framework, this change eliminates sending the (intermediate) state in
response to GCS_COMPSTR events.
Issue: https://github.com/flutter/flutter/issues/96209 (full fix)
Issue: https://github.com/flutter/flutter/issues/88645 (partial fix)
* iOS Background Platform Channels (#29665)
* added test that passes before this change, and fails after it
* started supporting backwards compatible usage of setting handlers
Users can add an expose_dirs entry to the program field in a
component's cml file to optionally expose extra directories
from their out/ directory.
BUG: fxbug.dev/89690
Warmup surface was being initialized on the platform thread rather than
the raster thread which was causing races in the skia cache, this change
just moves the warmup surface intiialization to the raster thread.
This change also addresses another minor problem where invoking shader
warmup with 0 skps would drop the callback on the floor and that would
cause the dart future to hang forever. Simply invoke the dart future if
no SKP's are provided.
