[HCPP] Properly remove hcpp views that are no longer visible #176742
Conversation
github-actions
bot
added
platform-android
|
As usual, golden images for your viewing. With change: |
|
@gaaclarke Reid suggested I request your review on hcpp stuff, but let me know if you don't think you're the right person to review here. |
gaaclarke
left a comment
gaaclarke
left a comment
There was a problem hiding this comment.
looking good, just a few questions and a swap of container is needed.
dev/integration_tests/android_engine_test/test_driver/hcpp/platform_view_clear_hidden_test.dart
Outdated
Show resolved
Hide resolved
engine/src/flutter/shell/platform/android/external_view_embedder/external_view_embedder_2.cc
Outdated
Show resolved
Hide resolved
engine/src/flutter/shell/platform/android/external_view_embedder/external_view_embedder_2.h
Outdated
Show resolved
Hide resolved
engine/src/flutter/shell/platform/android/jni/platform_view_android_jni.h
Show resolved
Hide resolved
| // If the previous frame had platform views, hide the overlay surface. | ||
| HideOverlayLayerIfNeeded(); | ||
| jni_facade_->applyTransaction(); | ||
| task_runners_.GetPlatformTaskRunner()->PostTask(fml::MakeCopyable( |
There was a problem hiding this comment.
Small additional change here, to clear the pvs also in the other branch of flow when there is no pv on screen but there was last frame, and then also to clear out the set.
I had thought this wasn't needed at first, but running the scrolling test again I found that without making these hide calls we still have a sliver of PV left on the screen, so it seems it is necessary both in the n->n-1 case as well as the 1->0 case.
I also moved this work to the same thread as the one we use for the onDisplayPlatformView2 work below. This is a follow up to the long discussion here #173881 (comment), though I don't think its necessary to fix this bug so I can revert it if you think it should be done in a follow up PR.
There was a problem hiding this comment.
it's fine, there is a bug in this change though that might be a pain to address. it might be worth putting it in a different pr, your call.
There was a problem hiding this comment.
Hmm it looks like moving this to the other thread is actually required, as it crashes without it (very interesting, because on the last PR we didn't understand how it wasn't crashing as is).
The way to fix this would normally be to make a shared/weak ptr and pass that in, right? But the this in question here is declared as unique so I can't do that
https://github.com/flutter/flutter/blob/master/engine/src/flutter/shell/platform/android/external_view_embedder/external_view_embedder_wrapper.cc#L37
I don't really understand the consequences of changing that here - would the fix here normally be to just make that make_shared instead of make_unique? Or is there another pattern that makes more sense here?
There was a problem hiding this comment.
I made the instance of this class shared, and then I used a weak ptr and explicitly copied. Let me know if any of that looks wrong.
I assume this is also a problem with the lines below, and if the fix here is right I should probably fix that in a follow up pr too?
https://github.com/flutter/flutter/blob/master/engine/src/flutter/shell/platform/android/external_view_embedder/external_view_embedder_2.cc#L163-L167
There was a problem hiding this comment.
Okay, I looked into this a bit more. What you've done is safe. It may not be what we want though. The safety we are adding here stops us from problems when we delete the AndroidExternalViewEmbedder2 without calling DestroySurfaces or calling SubmitFlutterView after having called DestroySurfaces. This is because DestroySurfaces synchronizes against the platform task runner.
nit: It would be nice to have some assertions in the code about what methods are intended to be called on what task runner. that can be done with TaskRunner::RunsTasksOnCurrentThread()
I think what I'd prefer is we go back to the unique_ptr. Capture the pointer explicitly and add a comment that the pointer is guaranteed to not be dangling as long as DestroySurfaces is called before the embedder is deleted. If you think there is a situation where that isn't the case we can keep the shared_ptr approach.
We are also modifying and reading overlay_layer_is_shown_ from different threads. That instance variable should be converted to an std::atomic at the least (make sure the .load() and .store() methods with the atomic).
There was a problem hiding this comment.
Changed back to using a unique pointer and added the comment
There was a problem hiding this comment.
change and comment looks good, thanks
There was a problem hiding this comment.
Also updated overlay_layer_is_shown_ to be atomic
engine/src/flutter/shell/platform/android/external_view_embedder/external_view_embedder_2.cc
Outdated
Show resolved
Hide resolved
engine/src/flutter/shell/platform/android/external_view_embedder/external_view_embedder_2.cc
Outdated
Show resolved
Hide resolved
…10229) Manual roll Flutter from e11e2c11288b to 7cd821c21093 (73 revisions) Manual roll requested by [email protected] flutter/flutter@e11e2c1...7cd821c 2025-10-14 [email protected] Fix computeDistanceToActualBaseline throws when accessing child size (flutter/flutter#176906) 2025-10-14 [email protected] iOS can set application locale before view controller is set (flutter/flutter#176592) 2025-10-14 [email protected] Roll ANGLE to a branch based on d9fa255a5c22 (flutter/flutter#176747) 2025-10-14 [email protected] Relands "Fixes keyboard selects disabled radio" (flutter/flutter#176977) 2025-10-14 [email protected] Fix expansion tile is missing state announcement on non-Apple platforms (flutter/flutter#175480) 2025-10-14 [email protected] impeller: allows access of float uniforms by name (flutter/flutter#176728) 2025-10-14 [email protected] Roll dart sdk to 3.11.0-17.0.dev (flutter/flutter#176947) 2025-10-13 [email protected] Move iOS integration tests (flutter/flutter#176940) 2025-10-13 [email protected] Make sure that an InputDatePickerFormField doesn't crash in 0x0 envir… (flutter/flutter#176047) 2025-10-13 [email protected] [web] Match the behavior of other platforms in Web Locale.toString if the country code is an empty string (flutter/flutter#176862) 2025-10-13 98614782+auto-submit[bot]@users.noreply.github.com Reverts "Fixes keyboard selects disabled radio (#176727)" (flutter/flutter#176958) 2025-10-13 [email protected] Fixes keyboard selects disabled radio (flutter/flutter#176727) 2025-10-13 [email protected] Roll Packages from e319c40 to d062181 (2 revisions) (flutter/flutter#176916) 2025-10-13 [email protected] Roll SwiftShader to 794b0cfce1d8 (flutter/flutter#176806) 2025-10-13 [email protected] Make DropdownMenu generic type non nullable (flutter/flutter#176711) 2025-10-12 [email protected] Roll Fuchsia Linux SDK from BWGpRvpdQh-HJpq1c... to _dd0Jv50H0oUI2Ad8... (flutter/flutter#176895) 2025-10-11 [email protected] Roll Fuchsia Linux SDK from JpiUsek1hU5r9QVKP... to BWGpRvpdQh-HJpq1c... (flutter/flutter#176880) 2025-10-11 [email protected] fix: content hash check for LUCI_CONTEXT (flutter/flutter#176867) 2025-10-11 [email protected] Feat: make tooltip position customizeable (flutter/flutter#175047) 2025-10-11 [email protected] Roll Dart SDK from d88d8bf2b53c to 65b171958c93 (3 revisions) (flutter/flutter#176871) 2025-10-11 [email protected] feat: apply radioGroup role to segmented control widgets (flutter/flutter#176157) 2025-10-10 [email protected] Make sure that a CheckboxMenuButton doesn't crash in 0x0 environment (flutter/flutter#176450) 2025-10-10 [email protected] [WebParagraph] Support for more styles, placeholders, decorations, etc (flutter/flutter#172853) 2025-10-10 [email protected] Set up a version of build_ios_framework_module_test that only runs on x64 machines and extend its timeout (flutter/flutter#176811) 2025-10-10 [email protected] Roll Packages from 0b41de3 to e319c40 (1 revision) (flutter/flutter#176833) 2025-10-10 [email protected] [tool/dap] Forward app.warning events from Flutter to DAP client (flutter/flutter#176827) 2025-10-10 [email protected] Roll Dart SDK from 70c00d3ceb3a to d88d8bf2b53c (1 revision) (flutter/flutter#176830) 2025-10-10 [email protected] Remove unnecessary nullable types in examples. (flutter/flutter#176713) 2025-10-10 [email protected] Roll Fuchsia Linux SDK from xArtL4DH0FsdwSqG_... to JpiUsek1hU5r9QVKP... (flutter/flutter#176822) 2025-10-10 [email protected] Cleanup OutlinedButton.icon documentation and implementation (flutter/flutter#176630) 2025-10-10 [email protected] [HCPP] Properly remove hcpp views that are no longer visible (flutter/flutter#176742) 2025-10-10 [email protected] Make sure that an InputChip doesn't crash in 0x0 environment (flutter/flutter#175930) 2025-10-10 [email protected] Update Flutter templates' Dart style (flutter/flutter#175963) 2025-10-10 [email protected] Make sure that a DropdownButtonFormField doesn't crash in 0x0 environ… (flutter/flutter#174958) 2025-10-10 [email protected] Make sure that an InkWell doesn't crash in 0x0 environment (flutter/flutter#175871) 2025-10-10 [email protected] Handle#6537 end drawer button (flutter/flutter#173026) 2025-10-10 [email protected] Roll Dart SDK from a9b7bd4b0b32 to 70c00d3ceb3a (4 revisions) (flutter/flutter#176815) 2025-10-10 [email protected] Change default Linux thread policy to merge platform and UI threads. (flutter/flutter#176759) 2025-10-09 [email protected] [ Tool ] Roll package:dwds to 26.0.0 (flutter/flutter#176808) 2025-10-09 [email protected] Update `CHANGELOG` to include 3.35.6 notes (flutter/flutter#176803) 2025-10-09 [email protected] Announce text and button together when DropdownMenu is treated as a button (flutter/flutter#176428) 2025-10-09 [email protected] [native_assets] create macOS CCompilerConfig via xcrun --find (flutter/flutter#175717) 2025-10-09 [email protected] [Impeller] Fix broken links in README. (flutter/flutter#176770) 2025-10-09 [email protected] Fix links to Custom Flutter Engine Embedders in README. (flutter/flutter#175807) ...
…#176742) Fixes flutter#175882. This ended up being a very similar bug to flutter#173881, and in my understanding comes from the same incorrect assumption. In old PV land these views would stop displaying if we stopped sending updates to them. But in HCPP the underlying implementation ends up using an Android SurfaceFlinger which continues displaying what it was last told to. So again we have a bug here were we aren't taking the new responsibility of clearing that we need to. See flutter#173881 (comment) Other solutions would be to just always call hide on the set of (keys of view_params which are not in composition order) on every frame (which would avoid this mirroring of state), or to modify the jni here to pass over one big bundle with all the information required to do all the existing calls as well as determine which views need to be hidden. But we are already doing this same mirroring of visibility state for the overlay layer (see Hide/ShowOverlayLayerIfNeeded()), so I think it is reasonable to take the same approach here. This is sort of a follow up to flutter#162908 as well, this PR properly removes the view when it is the last platform view, but does not fix the case that this PR attempts to more generally fix where we go from 2->1 (or n->n-1 > 0) pvs. ## Pre-launch Checklist - [x] I read the [Contributor Guide] and followed the process outlined there for submitting PRs. - [x] I read the [Tree Hygiene] wiki page, which explains my responsibilities. - [x] I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement]. - [x] I signed the [CLA]. - [x] I listed at least one issue that this PR fixes in the description above. - [x] I updated/added relevant documentation (doc comments with `///`). - [x] I added new tests to check the change I am making, or this PR is [test-exempt]. - [x] I followed the [breaking change policy] and added [Data Driven Fixes] where supported. - [x] All existing and new tests are passing. If you need help, consider asking for advice on the #hackers-new channel on [Discord]. **Note**: The Flutter team is currently trialing the use of [Gemini Code Assist for GitHub](https://developers.google.com/gemini-code-assist/docs/review-github-code). Comments from the `gemini-code-assist` bot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed. <!-- Links --> [Contributor Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#overview [Tree Hygiene]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md [test-exempt]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#tests [Flutter Style Guide]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md [Features we expect every widget to implement]: https://github.com/flutter/flutter/blob/main/docs/contributing/Style-guide-for-Flutter-repo.md#features-we-expect-every-widget-to-implement [CLA]: https://cla.developers.google.com/ [flutter/tests]: https://github.com/flutter/tests [breaking change policy]: https://github.com/flutter/flutter/blob/main/docs/contributing/Tree-hygiene.md#handling-breaking-changes [Discord]: https://github.com/flutter/flutter/blob/main/docs/contributing/Chat.md [Data Driven Fixes]: https://github.com/flutter/flutter/blob/main/docs/contributing/Data-driven-Fixes.md --------- Co-authored-by: Gray Mackall <[email protected]>
2 participants
Fixes #175882.
This ended up being a very similar bug to #173881, and in my understanding comes from the same incorrect assumption. In old PV land these views would stop displaying if we stopped sending updates to them. But in HCPP the underlying implementation ends up using an Android SurfaceFlinger which continues displaying what it was last told to. So again we have a bug here were we aren't taking the new responsibility of clearing that we need to. See #173881 (comment)
Other solutions would be to just always call hide on the set of (keys of view_params which are not in composition order) on every frame (which would avoid this mirroring of state), or to modify the jni here to pass over one big bundle with all the information required to do all the existing calls as well as determine which views need to be hidden. But we are already doing this same mirroring of visibility state for the overlay layer (see Hide/ShowOverlayLayerIfNeeded()), so I think it is reasonable to take the same approach here.
This is sort of a follow up to #162908 as well, this PR properly removes the view when it is the last platform view, but does not fix the case that this PR attempts to more generally fix where we go from 2->1 (or n->n-1 > 0) pvs.
Pre-launch Checklist
///).If you need help, consider asking for advice on the #hackers-new channel on Discord.
Note: The Flutter team is currently trialing the use of Gemini Code Assist for GitHub. Comments from the
gemini-code-assistbot should not be taken as authoritative feedback from the Flutter team. If you find its comments useful you can update your code accordingly, but if you are unsure or disagree with the feedback, please feel free to wait for a Flutter team member's review for guidance on which automated comments should be addressed.