fix(android): props 2.0 image tintColor=transparent broken (#57668)#57668
Open
bartlomiejbloniarz wants to merge 6 commits into
Open
fix(android): props 2.0 image tintColor=transparent broken (#57668)#57668bartlomiejbloniarz wants to merge 6 commits into
bartlomiejbloniarz wants to merge 6 commits into
Conversation
meta-cla
Bot
added
the
CLA Signed
facebook-github-tools
Bot
added
p: Software Mansion
|
@bartlomiejbloniarz has exported this pull request. If you are a Meta employee, you can view the originating Diff in D93140534. |
bartlomiejbloniarz
pushed a commit
that referenced
this pull request
Jul 27, 2026
Summary: Pull Request resolved: #57668 When enabling the props 2.0 feature flags I noticed that for an `<Image source={...} style={{ tintColor: 'transparent' }} />` the image is actually still showing, instead of becoming transparent. ### The underlying issue All color props are defined as `SharedColor`, where a `SharedColor` has a default value of `0`: https://github.com/facebook/react-native/blob/f3678f51d9873cb19602d7e36a4d8ed71562b9d0/packages/react-native/ReactCommon/react/renderer/graphics/platform/android/react/renderer/graphics/HostPlatformColor.h#L15-L18 https://github.com/facebook/react-native/blob/f3678f51d9873cb19602d7e36a4d8ed71562b9d0/packages/react-native/ReactCommon/react/renderer/graphics/Color.h#L30-L32 > [!NOTE] > This is a bit confusing to me. `0` is not really an "undefined" color, but its actually "transparent". What we are really saying this way is that all color props have a default value of "transparent". The naming makes me unsure whether this has been intentional. For other use cases, this seems to make sense. Ie. a user expects their text to have a background color of transparent/"nothing". However, we do not expect our image's tint color to have a default color of "transparent". This would hide all our images. With props 2.0 we use the `getDiffProp` function, and when we pass `tintColor: 'transparent'` it will be passed to native as `tintColor: 0`. When we then compare the passed prop's value vs the default value here, it will not include the `tintColor`: https://github.com/facebook/react-native/blob/f3678f51d9873cb19602d7e36a4d8ed71562b9d0/packages/react-native/ReactCommon/react/renderer/components/image/ImageProps.cpp#L249-L251 `tintColor` really is an optional color prop, and should be treated as such. The best fix I found was therefor making it really an `std::optional`. Let me know if you think otherwise! ## Changelog: <!-- Help reviewers and the release process by writing your own changelog entry. Pick one each for the category and type tags: [ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message For more details, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [ANDROID] [CHANGED] - ImageProps make `tintColor` an `std::optional` to support color `transparent` (`0`) with props 2.0 X-link: #55535 Test Plan: - In the RNTester app change one of the Tint Color image examples to use tintColor of "transparent" - The image should be invisible now as all visible pixels turned transparent - Enable the props 2.0 feature flags - Run the same example, notice that the tintColor has not been applied Reviewed By: lenaic Differential Revision: D93140534 Pulled By: bartlomiejbloniarz
bartlomiejbloniarz
force-pushed
the
export-D93140534
branch
from
July 27, 2026 07:42
d9bc820 to
715bf9c
Compare
meta-codesync
Bot
changed the title
Summary: Pull Request resolved: #57581 Adds the `enableMountingCoordinatorPullModelAndroid` experiment flag (default off) that gates the Android pull-model mounting migration. Config entry plus regenerated accessors only — no behavior change. ## Changelog: [Android] [Added] - Add `enableMountingCoordinatorPullModelAndroid` feature flag Reviewed By: rubennorte Differential Revision: D112309049
Summary: Pull Request resolved: #57580 Java side of the pull model — dead code until the C++ wiring lands: - `PullTransactionMountItem`: asks C++ (via `FabricUIManagerBinding.pullAndExecuteTransaction`) to pull the surface's pending transaction and apply it synchronously on the UI thread. - `FabricUIManager.onTransactionAvailable` (JNI entry): enqueues a `PullTransactionMountItem`. - `FabricUIManagerBinding.pullAndExecuteTransaction`: extern declaration. One item is enqueued per notification, mirroring iOS; redundant items no-op in C++. ## Changelog: [Android] [Added] - Add inert Java plumbing (`PullTransactionMountItem`, `FabricUIManager.onTransactionAvailable`) for the pull model Reviewed By: rubennorte Differential Revision: D112309050
Summary: Pull Request resolved: #57579 Makes `enableMountingCoordinatorPullModelAndroid` functional. With the flag on, the commit thread only signals transaction availability and the UI thread pulls and applies at mount time (matching iOS/macOS); with the flag off (default), behavior is byte-for-byte identical. - `schedulerShouldRenderTransactions`: notifies via JNI (`FabricMountingManager::onTransactionAvailable`) instead of pulling and building the batch. - `schedulerDidFinishTransaction`: no-op under the pull model. - `FabricUIManagerBinding::pullAndExecuteTransaction` (new JNI method): pulls the surface's transaction on the UI thread and runs `executeMount`. - `FabricMountingManager::executeMount`: gains a `synchronous` mode that executes the batch directly on the UI thread. - The accumulation sites remain gated on `enableAccumulatedUpdatesInRawPropsAndroid`; the pull model requires that flag to be co-enabled, since a pull may collapse several commits into one diff and therefore needs complete accumulated rawProps. ## Changelog: [Android] [Added] - Wire the pull-model mounting path in C++ behind `enableMountingCoordinatorPullModelAndroid` Reviewed By: christophpurrer Differential Revision: D112309053
Summary: Pull Request resolved: #57583 Robolectric tests for the notification path: a notification pulls synchronously on the UI thread; one pull item is enqueued per notification and dispatched in order (redundant pulls no-op in C++); no binding is a clean no-op. Adds `ShadowFabricUIManagerBinding` and `ShadowPerformanceTracer` shadows. ## Changelog: [Internal] - Add JVM tests for the Android pull-model plumbing Reviewed By: cortinico Differential Revision: D112309051
Summary: Pull Request resolved: #57607 Adds the `enableImageTransparentTintColor` experiment flag (default off) that gates whether a defined transparent Image `tintColor` (alpha 0) is applied as a real tint (rendering the image invisible) or treated as unassigned/untinted. Config entry plus regenerated accessors only — no behavior change. ## Changelog: [General] [Added] - Add `enableImageTransparentTintColor` feature flag Reviewed By: lenaic Differential Revision: D112572558
Summary: Pull Request resolved: #57668 When enabling the props 2.0 feature flags I noticed that for an `<Image source={...} style={{ tintColor: 'transparent' }} />` the image is actually still showing, instead of becoming transparent. ### The underlying issue All color props are defined as `SharedColor`, where a `SharedColor` has a default value of `0`: https://github.com/facebook/react-native/blob/f3678f51d9873cb19602d7e36a4d8ed71562b9d0/packages/react-native/ReactCommon/react/renderer/graphics/platform/android/react/renderer/graphics/HostPlatformColor.h#L15-L18 https://github.com/facebook/react-native/blob/f3678f51d9873cb19602d7e36a4d8ed71562b9d0/packages/react-native/ReactCommon/react/renderer/graphics/Color.h#L30-L32 > [!NOTE] > This is a bit confusing to me. `0` is not really an "undefined" color, but its actually "transparent". What we are really saying this way is that all color props have a default value of "transparent". The naming makes me unsure whether this has been intentional. For other use cases, this seems to make sense. Ie. a user expects their text to have a background color of transparent/"nothing". However, we do not expect our image's tint color to have a default color of "transparent". This would hide all our images. With props 2.0 we use the `getDiffProp` function, and when we pass `tintColor: 'transparent'` it will be passed to native as `tintColor: 0`. When we then compare the passed prop's value vs the default value here, it will not include the `tintColor`: https://github.com/facebook/react-native/blob/f3678f51d9873cb19602d7e36a4d8ed71562b9d0/packages/react-native/ReactCommon/react/renderer/components/image/ImageProps.cpp#L249-L251 `tintColor` really is an optional color prop, and should be treated as such. The best fix I found was therefor making it really an `std::optional`. Let me know if you think otherwise! ## Changelog: <!-- Help reviewers and the release process by writing your own changelog entry. Pick one each for the category and type tags: [ANDROID|GENERAL|IOS|INTERNAL] [BREAKING|ADDED|CHANGED|DEPRECATED|REMOVED|FIXED|SECURITY] - Message For more details, see: https://reactnative.dev/contributing/changelogs-in-pull-requests --> [ANDROID] [CHANGED] - ImageProps make `tintColor` an `std::optional` to support color `transparent` (`0`) with props 2.0 X-link: #55535 Test Plan: - In the RNTester app change one of the Tint Color image examples to use tintColor of "transparent" - The image should be invisible now as all visible pixels turned transparent - Enable the props 2.0 feature flags - Run the same example, notice that the tintColor has not been applied Reviewed By: lenaic Differential Revision: D93140534 Pulled By: bartlomiejbloniarz
bartlomiejbloniarz
force-pushed
the
export-D93140534
branch
from
July 27, 2026 10:31
715bf9c to
315ea5d
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary:
When enabling the props 2.0 feature flags I noticed that for an
<Image source={...} style={{ tintColor: 'transparent' }} />the image is actually still showing, instead of becoming transparent.The underlying issue
All color props are defined as
SharedColor, where aSharedColorhas a default value of0:https://github.com/facebook/react-native/blob/f3678f51d9873cb19602d7e36a4d8ed71562b9d0/packages/react-native/ReactCommon/react/renderer/graphics/platform/android/react/renderer/graphics/HostPlatformColor.h#L15-L18
https://github.com/facebook/react-native/blob/f3678f51d9873cb19602d7e36a4d8ed71562b9d0/packages/react-native/ReactCommon/react/renderer/graphics/Color.h#L30-L32
Note
This is a bit confusing to me.
0is not really an "undefined" color, but its actually "transparent". What we are really saying this way is that all color props have a default value of "transparent". The naming makes me unsure whether this has been intentional.For other use cases, this seems to make sense. Ie. a user expects their text to have a background color of transparent/"nothing". However, we do not expect our image's tint color to have a default color of "transparent". This would hide all our images.
With props 2.0 we use the
getDiffPropfunction, and when we passtintColor: 'transparent'it will be passed to native astintColor: 0. When we then compare the passed prop's value vs the default value here, it will not include thetintColor:https://github.com/facebook/react-native/blob/f3678f51d9873cb19602d7e36a4d8ed71562b9d0/packages/react-native/ReactCommon/react/renderer/components/image/ImageProps.cpp#L249-L251
tintColorreally is an optional color prop, and should be treated as such. The best fix I found was therefor making it really anstd::optional. Let me know if you think otherwise!Changelog:
[ANDROID] [CHANGED] - ImageProps make
tintColoranstd::optionalto support colortransparent(0) with props 2.0X-link: #55535
Test Plan:
Reviewed By: lenaic
Differential Revision: D93140534
Pulled By: bartlomiejbloniarz