Allow touches on overflowed children when `overflow: visible` (Android) #26374

danielgindi · 2019-09-08T09:22:31Z

Summary

Currently overflow: visible allows showing child views that are outside the parent's bounds (well, overflow: visible on the grandparent allows that, not the parent).
But those non-clipped children do not receive touches.

This is an attempt to solve it.

Changelog

[Android] [Fixed] - overflow: visible now allows interaction with children that are rendered outside their parents' bounds.

Test Plan

Added overflow: visible, tapped on a button.
Added a MapView, tested scrolling the map while overflowed elements are visible over it, and tapping on those elements.

danielgindi · 2019-09-08T14:46:45Z

For some reason the CI fails, without any details.

Summary: Adds support for the `overflow` style property on React Native for Android. This is the second attempt to do this. See 6110a4c (D8666509) for the first attempt. Similar to the first attempt, this sets `setClipChildren(false)` by default on all `ViewGroup` instances. However, this differs in how it implements `overflow: hidden`. Instead of conditionally setting `setClipChildren`, this manually clips children to the `ViewGroup`'s bounds (which was incidentally what we were doing for background + border radius already). Reviewed By: achen1 Differential Revision: D8690805 fbshipit-source-id: 58757825cd9d138c18c8758918d85b4ca1915f87

nick-michael · 2019-11-16T01:39:19Z

Can anyone trigger a rebuild of this? Maybe was just a bad day for CI?
@danielgindi if you could just force-push the same commit I guess that would trigger

danielgindi · 2019-11-16T18:03:36Z

@nick-michael Rebasing on latest master

danielgindi · 2019-11-16T18:14:46Z

I'm guessing another bad day for CI?

nick-michael · 2019-11-16T20:13:57Z

Haha guess not, I don't want this to get forgotten about though, this is such a welcome change for RN android

ltcaosj · 2019-11-22T03:27:29Z

We really need to PR merged :). Same stuff is working fine on iOS, not on Android.

kdenz · 2019-11-28T08:46:19Z

Yes we'll need this urgently too, because we have an expandable button which will go overflow and open an animated view action menu, and right now on android users cannot interact with the expanded content directly. Changing pointerEvents and zIndex doesn't work.

ltcaosj · 2019-11-28T14:45:31Z

@danielgindi What should we do to resolve the CI issue? Your fixing is so much import to us and the react-native community. After fixing this one we can create a complex UI much easier.

danielgindi · 2019-12-01T09:11:40Z

@ltcaosj I have no idea. RN does not compile easily, and I can't spend too much time forcing it to and then troubleshooting their CI scripts. I did not even touch the iOS code, but the CI is failing on iOS. So I'm not going to even try to solve this, as it's not my issue.

Edit: Not trying to be negative here. Just a bit (a lot?) frustrated by unrelated errors being thrown all around for absolutely no reason. I see that this one is important to a lot of people, so if anyone has a few hours to spare, please do try to look into it. I will try also but I do not have a lot of free time these days.

fabOnReact · 2019-12-31T14:55:42Z

ci/circleci: js_coverage — Your tests failed on CircleCI

#!/bin/bash -eo pipefail
yarn test --coverage --maxWorkers=2
cat ./coverage/lcov.info | ./node_modules/.bin/coveralls

All test succed,

Test Suites: 102 passed, 102 total
Tests:       1 skipped, 981 passed, 982 total
Snapshots:   477 passed, 477 total
Time:        94.842s
Ran all test suites.
Done in 95.74s.

but command /home/circleci/react-native/node_modules/coveralls/bin/coveralls.js fails

/home/circleci/react-native/node_modules/coveralls/bin/coveralls.js:18
        throw err;
        ^
Bad response: 422 {"message":"Couldn't find a repository matching this job.","error":true}
Exited with code 1

this errors is connected to misconfiguration inside circleci of the coveralls js library.

A quick search online makes me think about the following issues:

More issues open for this:
lemurheavy/coveralls-public#632
lemurheavy/coveralls-public#487
lemurheavy/coveralls-public#713

tarasvakulka · 2020-01-13T10:17:09Z

Hi, may be somebody know when this PR will be merged ?

danielgindi · 2020-02-16T09:03:59Z

@kelset @alloy I know you guys are busy, but this solves a fundamental issue with Android... Can you please take the time to review?

Summary: Allow you to harvest the `UIAccessibilityContrastHigh` trait from iOS to show accessible colors when high contrast mode is enabled. ```jsx // usage PlatformColorIOS({ light: '#eeeeee', dark: '#333333', highContrastLight: '#ffffff', highContrastDark: '#000000', }); // { // "dynamic": { // "light": "#eeeeee", // "dark": "#333333", // "highContrastLight": "#ffffff", // "highContrastDark": "#000000", // } // } ``` This is how apple's own dynamic system colors work under the hood (https://developer.apple.com/design/human-interface-guidelines/ios/visual-design/color/#dynamic-system-colors) --- The react native docs mention that more keys may become available in the future, which this PR is adding: > In the future, more keys might become available for different user preferences, like high contrast. https://reactnative.dev/docs/dynamiccolorios ## Changelog  [iOS] [Added] - High contrast dynamic color options for dark and light mode. Pull Request resolved: facebook#31651 Test Plan: Added unit tests for `normalizeColor` to pass the high contrast colors downstream to RCTConvert Reviewed By: lunaleaps Differential Revision: D28922536 Pulled By: p-sun fbshipit-source-id: f81417f003c3adefac50e994e62b9be14ffa91a1

…acebook#31062) Summary: A recent commit facebook@941bc0e#diff-0eeea47fa4bace26fa6c492a03fa0ea3923a2d8d54b7894f7760cb9131ab65eb on Hermes macOS brings a regression for Mac Catalyst target. Once hardcoded cli bundle platform `ios` can now be either `ios` or `macos`. However, Mac Catalyst is identified as `macos` rather than `ios`. This PR should fix it and close facebook#31061. ## Changelog [iOS] [Fixed] - Fix cli bundle platform for Mac Catalyst in `react-native-xcode.sh` Pull Request resolved: facebook#31062 Test Plan: 1. Build fails on a new RN 0.64-rc.3 project. 2. Apply the fix. 3. Build passes. Reviewed By: TheSavior Differential Revision: D29038793 Pulled By: appden fbshipit-source-id: 29761f887ec7a9cc26f088953c3888c6d19bed71

Summary: This PR bumps Fresco to 2.5.0, which is first version on MavenCentral since jCenter announcement. ## Changelog [Android] [Changed] - Bump Fresco to 2.5.0 Pull Request resolved: facebook#31699 Test Plan: CI is green Reviewed By: TheSavior Differential Revision: D29031847 Pulled By: passy fbshipit-source-id: 486ffbf5461d07d736c0ebe17c0c7726937db344

Summary: Pull Request resolved: facebook#31675 As requested in parent diff, moved the Android dep bumps into a separate diff. ## Changelog [general][changed] - [Android] Update Flipper to 0.93.0 Reviewed By: mdvacca, ShikaSD Differential Revision: D28688486 fbshipit-source-id: c3a8e0edeebdabd490b2885497e261f64bdab4bd

Summary: Updating pods attempts to bump fmt to 7.1.3, which causes CircleCI to fail. [Sample failure](https://app.circleci.com/pipelines/github/facebook/react-native/9422/workflows/f4c9076a-9649-490c-b565-555fecc60957/jobs/205827). Let's temporarily lock to an older version until the [fmt fix](fmtlib/fmt@355be4b) gets tagged for release. Reviewed By: JoshuaGross Differential Revision: D29147585 fbshipit-source-id: b1aca9618586a9d6e4c6d0c2c37b258745e008ee

…)"" This reverts commit a10a201.

This reverts commit 0a15927.

Summary: The native libraries are compiled outside of the usual Android build flow using separate CLI task. Because of that, shared native libraries may not exist when AAR is bundled, resulting in weird sequencing issues. This change updates gradle dependency graph, executing RN native build before Android part (as it is done in RNTester already). Changelog: [Internal] Reviewed By: mdvacca Differential Revision: D29209249 fbshipit-source-id: 36386c78996b1cd9b1731735e36e571199e9e81b

…lPointerException: bio == null crash (facebook#31822) Summary: Douring our routine crash report check we are occasionally seeing reports of exceptions like this in the wild from our crash stack: ``` java.lang.NullPointerException: bio == null at com.android.org.conscrypt.NativeCrypto.SSL_pending_written_bytes_in_BIO(NativeCrypto.java) at com.android.org.conscrypt.NativeSsl$BioWrapper.getPendingWrittenBytes(NativeSsl.java:660) at com.android.org.conscrypt.ConscryptEngine.pendingOutboundEncryptedBytes(ConscryptEngine.java:566) at com.android.org.conscrypt.ConscryptEngineSocket.drainOutgoingQueue(ConscryptEngineSocket.java:584) at com.android.org.conscrypt.ConscryptEngineSocket.close(ConscryptEngineSocket.java:480) at okhttp3.internal.Util.closeQuietly(Util.kt:501) at okhttp3.internal.connection.ExchangeFinder.findConnection(ExchangeFile:245) at okhttp3.internal.connection.ExchangeFinder.findHealthyConnection(ExchangeFile:106) at okhttp3.internal.connection.ExchangeFinder.find(ExchangeFile:74) at okhttp3.internal.connection.RealCall.initExchange$okhttp(ExchangeFile:255) at okhttp3.internal.connection.ConnectInterceptor.intercept(ExchangeFile:32) ... ``` ![Screen Shot 2021-07-07 at 1 38 23 PM](https://user-images.githubusercontent.com/8868908/124711795-b5fee980-df28-11eb-98c4-9668661340b6.png) This appears to only be happening on devices running Android 10 and 11. This happens because there is concurrency issue in Conscrypt where two threads race to close an SSLEngine-based SSLSocket and access to the underlying BIO is unsynchronized. **The OkHttp team already released a fix for this issue on version 4.9.1** this PR aims to update our OkHttp package to version 4.9.1. Related discussion: [https://issuetracker.google.com/issues/177450597](https://issuetracker.google.com/issues/177450597) [https://publicobject.com/2021/01/30/bio-null/](https://publicobject.com/2021/01/30/bio-null/) cc dulmandakh fkgozali ## Changelog [Android] [Changed] - Bumping OkHttp from 4.9.0 to 4.9.1. Pull Request resolved: facebook#31822 Test Plan: Manual & Automated from CI Reviewed By: fkgozali Differential Revision: D29590198 Pulled By: ShikaSD fbshipit-source-id: 4228bfd3472114253e13acb436dc1dd9287a148d

Summary: Fixes facebook#31774. This pull request resolves a problem related to accessing blobs greater than 64 KB on Android. When an object URL for such blob is passed as source of `<Image />` component, the image does not load. This issue was related to the fact that pipe buffer has a limited capacity of 65536 bytes (https://man7.org/linux/man-pages/man7/pipe.7.html, section "Pipe capacity"). If there is more bytes to be written than free space in the buffer left, the write operation blocks and waits until the content is read from the pipe. The current implementation of `BlobProvider.openFile` first creates a pipe, then writes the blob data to the pipe and finally returns the read side descriptor of the pipe. For blobs larger than 64 KB, the write operation will block forever, because there are no readers to empty the buffer. https://github.com/facebook/react-native/blob/41ecccefcf16ac8bcf858dd955af709eb20f7e4a/ReactAndroid/src/main/java/com/facebook/react/modules/blob/BlobProvider.java#L86-L95 This pull request moves the write operation to a separate thread. The read side descriptor is returned immediately so that both writer and reader can work simultaneously. Reading from the pipe empties the buffer and allows the next chunks to be written. ## Changelog  [Android] [Fixed] - Fix support for blobs larger than 64 KB Pull Request resolved: facebook#31789 Test Plan: A new example has been added to RN Tester app to verify if the new implementation properly loads the image of size 455 KB from a blob via object URL passed as image source. <img src="https://user-images.githubusercontent.com/20516055/123859163-9eba6d80-d924-11eb-8a09-2b1f353bb968.png" alt="Screenshot_1624996413" width="300" /> Reviewed By: ShikaSD Differential Revision: D29674273 Pulled By: yungsters fbshipit-source-id: e0ac3ec0a23690b05ab843061803f95f7666c0db

Summary: # See PR facebook#29728 # From PR Author Using `PlatformColor` with border colors doesn't work currently when switching dark mode as the information is lost when converting to `CGColor`. This change keeps the border colors around as `UIColor` so switching to dark mode works. ```ts <View style={{ borderColor: DynamicColorIOS({ dark: "yellow", light: "red" }), borderWidth: 1, }} > ... </View> ``` This view will start with a red border (assuming light mode when started), but will not change to a yellow border when switching to dark mode. With this PR, the border color will be correctly set to yellow. ## Changelog [iOS] [Fixed] - Allow PlatformColor to work with border colors Pull Request resolved: facebook#29728 Test Plan: 1. Assign a `PlatformColor` or `DynamicColorIOS` to a view border color. 2. Toggle between dark / light mode. See the colors change. Reviewed By: lunaleaps Differential Revision: D29268376 Pulled By: p-sun fbshipit-source-id: 586545b05be0beb0e6e5ace6e3f74b304620ad94

* Bump Flipper to 0.93 (facebook#31708) Summary: Pull Request resolved: facebook#31708 Changelog: [general][changed] - [iOS] Update Flipper to 0.93.0 Reviewed By: PeteTheHeat Differential Revision: D29060305 fbshipit-source-id: 2ff109930437bfc90e8ce441fa681de867206397 * Update Podfile.lock * bump(hermes): bumped hermes to 0.8.1 While current dependencies included the new version in the range, bumping it make sure that no one use the old one because of a lock file Co-authored-by: Michel Weststrate <mweststrate@fb.com>

pull-bot · 2021-07-26T07:33:52Z

	Fails
🚫	❗ Base Branch - The base branch for this PR is something other than `master`. Are you sure you want to target something other than the `master` branch?

	Warnings
⚠️	🔒 package.json - Changes were made to package.json. This will require a manual import by a Facebook employee.

Generated by 🚫 dangerJS against c6c3aa2

danielgindi · 2021-08-07T06:50:41Z

Finally, the PR by @hsource was merged. This older one is now obsolete.
My merged branch will still be available for use until this will be released, then I'll delete it.

facebook-github-bot added the CLA Signed This label is managed by the Facebook bot. Authors need to sign the CLA before a PR can be reviewed. label Sep 8, 2019

react-native-bot added Bug Platform: Android Android applications. labels Sep 8, 2019

danielgindi mentioned this pull request Sep 8, 2019

[0.57.1] Android overflow doesn't register taps (touchable) in the "overflowed" area #21455

Closed

3 tasks

danielgindi force-pushed the feature/android_clip_touches branch from 8655e56 to 5b06654 Compare October 4, 2019 06:57

nick-michael mentioned this pull request Nov 7, 2019

i have a problem with touchable is not working in android, when one view is overlapping on another view #27061

Closed

qalqi mentioned this pull request Nov 13, 2019

onPress cannot work outside the ViewOverflow area. entria/react-native-view-overflow#13

Closed

danielgindi force-pushed the feature/android_clip_touches branch from 5b06654 to ac2a12f Compare November 16, 2019 18:03

danielgindi requested review from cpojer, hramos and shergin as code owners November 16, 2019 18:03

danielgindi force-pushed the feature/android_clip_touches branch from ac2a12f to 9a0154f Compare November 16, 2019 18:09

daisylb mentioned this pull request Nov 18, 2019

React Native Android: An absolute positioned, TouchableOpacity outside of the bounds of its parent is not clickable #27232

Closed

ltcaosj mentioned this pull request Nov 22, 2019

0.62.x Discussion react-native-community/releases#145

Closed

narobertson42 mentioned this pull request Dec 11, 2019

0.61.5 Discussion react-native-community/releases#154

Closed

kelset mentioned this pull request Jan 21, 2020

0.62.x RC Discussion react-native-community/releases#157

Closed

6 tasks

chipsnyder mentioned this pull request Feb 11, 2020

FloatingToolbar ideal version wordpress-mobile/gutenberg-mobile#1414

Closed

birkir and others added 17 commits June 16, 2021 16:40

[LOCAL] lock files update for 065 branch

ca5b943

[0.65.0-rc.1] Bump version numbers

0e08b25

Revert "Revert "Gradle 6.9, Android Gradle Plugin 4.2.1 (facebook#31593…

be9a669

…)"" This reverts commit a10a201.

Revert "Revert "bump buildToolsVersion to 30.0.2 (facebook#31627)""

ba4424f

This reverts commit 0a15927.

[0.65.0-rc.2] Bump version numbers

db7aa7b

fix(deps): bump metro to 0.66.2 + dedup (facebook#31886)

e40f582

[0.65.0-rc.3] Bump version numbers

e8d725a

danielgindi force-pushed the feature/android_clip_touches branch from e64cc28 to 4f72040 Compare July 26, 2021 07:28

danielgindi and others added 4 commits July 26, 2021 13:47

Allow touches on overflowed children when overflow: 'visible'

1b8dddc

Moved overflow property declarations to interface

719f271

Fixed overflow consideration from child

3920241

Borrowed the RNTest PointerEvents example by @hsource

c6c3aa2

danielgindi force-pushed the feature/android_clip_touches branch from 4f72040 to c6c3aa2 Compare July 26, 2021 10:47

danielgindi requested a review from mhorowitz as a code owner July 26, 2021 10:47

danielgindi closed this Aug 7, 2021

Stafox mentioned this pull request May 20, 2024

Touchable area of context menu is too small on Android mpiannucci/react-native-context-menu-view#119

Open

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Allow touches on overflowed children when `overflow: visible` (Android) #26374

Allow touches on overflowed children when `overflow: visible` (Android) #26374

danielgindi commented Sep 8, 2019 •

edited

Loading

danielgindi commented Sep 8, 2019

nick-michael commented Nov 16, 2019 •

edited

Loading

danielgindi commented Nov 16, 2019 •

edited

Loading

danielgindi commented Nov 16, 2019

nick-michael commented Nov 16, 2019

ltcaosj commented Nov 22, 2019

kdenz commented Nov 28, 2019

ltcaosj commented Nov 28, 2019

danielgindi commented Dec 1, 2019 •

edited

Loading

fabOnReact commented Dec 31, 2019 •

edited

Loading

tarasvakulka commented Jan 13, 2020

danielgindi commented Feb 16, 2020

pull-bot commented Jul 26, 2021 •

edited

Loading

danielgindi commented Aug 7, 2021

Allow touches on overflowed children when overflow: visible (Android) #26374

Allow touches on overflowed children when overflow: visible (Android) #26374

Conversation

danielgindi commented Sep 8, 2019 • edited Loading

Summary

Changelog

Test Plan

danielgindi commented Sep 8, 2019

nick-michael commented Nov 16, 2019 • edited Loading

danielgindi commented Nov 16, 2019 • edited Loading

danielgindi commented Nov 16, 2019

nick-michael commented Nov 16, 2019

ltcaosj commented Nov 22, 2019

kdenz commented Nov 28, 2019

ltcaosj commented Nov 28, 2019

danielgindi commented Dec 1, 2019 • edited Loading

fabOnReact commented Dec 31, 2019 • edited Loading

tarasvakulka commented Jan 13, 2020

danielgindi commented Feb 16, 2020

pull-bot commented Jul 26, 2021 • edited Loading

danielgindi commented Aug 7, 2021

Allow touches on overflowed children when `overflow: visible` (Android) #26374

Allow touches on overflowed children when `overflow: visible` (Android) #26374

danielgindi commented Sep 8, 2019 •

edited

Loading

nick-michael commented Nov 16, 2019 •

edited

Loading

danielgindi commented Nov 16, 2019 •

edited

Loading

danielgindi commented Dec 1, 2019 •

edited

Loading

fabOnReact commented Dec 31, 2019 •

edited

Loading

pull-bot commented Jul 26, 2021 •

edited

Loading