Skip to content

patch imagepickerios video widths #3

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Merged
merged 2 commits into from
Jul 11, 2019

Conversation

victorias
Copy link

original PR was #2, redoing this to merge it into .59

@victorias victorias merged commit df150d2 into 0.59.10-discord Jul 11, 2019
@victorias victorias deleted the patch/video-widths-.59 branch July 11, 2019 17:56
Fanghao pushed a commit that referenced this pull request Sep 12, 2019
* patch ImagePickerIOS to also give a width and height if it
detects movies

* clean up
paulshen pushed a commit that referenced this pull request Jan 14, 2020
* patch ImagePickerIOS to also give a width and height if it
detects movies

* clean up
jonwu pushed a commit that referenced this pull request Nov 24, 2020
Summary:
This diff allows specifying the preemptive compilation threshold via CompileFlags.
Users get a toggle in CLI and RuntimeConfig that allows choosing between 1. fully eager, 2. fully lazy, 3. use default thresholds ("smart"). The default is #3.

However, since we use `-O` by default, it overrides any lazy compilation when
using the `hermes` binary.

ChangeLog: [Internal] Inspector updated to use new RuntimeConfig laziness control

Reviewed By: tmikov

Differential Revision: D23356463

fbshipit-source-id: 508b7b2e6a218346c69acfec97e7891e388f0e9b
mrkcsc pushed a commit that referenced this pull request Oct 8, 2021
Summary:
Previous iterations of this diff that were reverted: D30678341 (facebook@8009459), D30868627 (facebook@abd0f38).

With the power of selects, we can move the base AppleTVOS flags into the regular
base Apple flags.

While I'm here, drop the third `p` in `get_application_apppletvos_flags()` as
it's driving me insane.

Note - This puts get_visibility_option() on all Apple builds.  I believe this is
the right thing to do as everything except macOS static libraries already do it,
and it shouldn't affect binaries.

Changelog: [Internal]

Reviewed By: mzlee, jdonald

Differential Revision: D31024459

fbshipit-source-id: be85296cda3612836c1c74632dc52f6e3f89512e
mrkcsc pushed a commit that referenced this pull request Oct 8, 2021
…ake #3)

Differential Revision:
D31024459 (facebook@0a46e5e)

Original commit changeset: be85296cda36

fbshipit-source-id: ceb8e5a3cda57a40a876b07133d8021942308878
denbeigh2000 pushed a commit that referenced this pull request Apr 19, 2022
Summary:
This diff adds `overflowInset` values in RN Android. These values are used to give  an enlarged boundary of a view group that also contains all its children layout. Here is [the post](https://fb.workplace.com/groups/yogalayout/permalink/2264980363573947/) that discuss more on why this is useful. I steal the pic in that post here as TLDR:

{F687030994}

In the above case, we will get overflowInset for ViewGroup A as something like `top: 0, right: -20, bottom: -20, left: 0`.

This has been added in the [Fabric core](https://fburl.com/code/f8c5tg7b) and [in IOS](https://fburl.com/code/vkh0hpt6). In Android, since we used to ignore all event coordinates outside of a ViewGroup boundary, this is not an issue. However, that caused unregistered touch area problem and got fixed in D30104853 (facebook@e35a963), which dropped the boundary check and made the hit test algorithm in [TouchTargetHelper.java](https://fburl.com/code/dj8jiz22) worse as we now need to explore all the child node under ReactRootNode.

This perf issue is getting obvious when a view loads too many items, which matches our experience with "Hover getting slow after scrolling", "Hover getting slow after going back from PDP view", and "The saved list view (in Explore) is very fast (because it has very few components)"

To fix this issue, I added the support to `overflowInset` to RN Android by
1. Sending the `overflowInset` values from Binding.cpp in RN Android as a separate mount instruction
2. Update `IntBufferBatchMountItem.java` to read the int buffer sent over JNI, and pass the `overflowInset` values to `SurfaceMountingManager.java`
3. Creating new interface `ReactOverflowViewWithInset.java` and extending the existing `ReactOverflowView.java` usages
4. Adding implementation of getter and setter for `overflowInset` in various views
5. Update `TouchTargetHelper.java` to read the values and check boundaries before exploring ViewGroup's children

Note that in #3 I didn't change `ReactOverflowView.java` interface directly. I am concerned about backward compatibility issues in case this interface is being used in OSS. I suggest we deprecate it as we are not using it anymore in our code.

Changelog:
[Internal][Android]

Reviewed By: JoshuaGross

Differential Revision: D33133977

fbshipit-source-id: 64e3e837fe7ca6e6dbdbc836ab0615182e10f28c
Flewp pushed a commit that referenced this pull request Apr 7, 2025
Summary:
Pull Request resolved: facebook#50147

Noticed a couple bugs here, around a crash from assertion internal to the caching map which hashes on the AttributedString, that may or may not be related.

1. We are missing `baseTextAttributes` for both hashing and equality (which is mostly innocuous, but still wrong)
2. We were not hashing or comparing `textAlignVertical`
3. For equality, we were comparing parent shadow view tag and metrics, but for hashing, we were hashing the whole ShadowView.

I think #3 could cause issues, since we could see different hash despite equality, which could break invariants.

Changelog: [Internal]

Reviewed By: lunaleaps

Differential Revision: D71500246

fbshipit-source-id: 462749d5ca10d10bf0dab88089253a2bb8e603fb
hannomargelo pushed a commit that referenced this pull request May 20, 2025
…tion for existing view (facebook#51294)

Summary:
Pull Request resolved: facebook#51294

changelog: [internal]

Fix a crash where a node that is supposed to be culled doesn't get visited because culling context is not updated.
The differentiator would generate a create instruction for a view that already exists.

Stack trace for the crash:
```
* thread #1, queue = 'com.apple.main-thread', stop reason = signal SIGABRT
  * frame #0: 0x0000000111740874 libsystem_kernel.dylib`__pthread_kill + 8
    frame #1: 0x00000001117aa2ec libsystem_pthread.dylib`pthread_kill + 264
    frame #2: 0x0000000180171ea8 libsystem_c.dylib`abort + 100
    frame #3: 0x00000001802b0144 libc++abi.dylib`abort_message + 128
    frame #4: 0x000000018029fe4c libc++abi.dylib`demangling_terminate_handler() + 296
    frame #5: 0x000000018006f220 libobjc.A.dylib`_objc_terminate() + 124
    frame #6: 0x00000001375d1964 INFRAFramework`meta_terminate() + 5468
    frame #7: 0x00000001802af570 libc++abi.dylib`std::__terminate(void (*)()) + 12
    frame #8: 0x00000001802b2498 libc++abi.dylib`__cxxabiv1::failed_throw(__cxxabiv1::__cxa_exception*) + 32
    frame #9: 0x00000001802b2478 libc++abi.dylib`__cxa_throw + 88
    frame #10: 0x0000000180093904 libobjc.A.dylib`objc_exception_throw + 384
    frame #11: 0x0000000180e6999c Foundation`-[NSAssertionHandler handleFailureInFunction:file:lineNumber:description:] + 268
    frame #12: 0x000000031a3bcfc8 XPLAT_6_Framework`-[RCTComponentViewRegistry dequeueComponentViewWithComponentHandle:tag:] + 528
    frame #13: 0x000000031a3ccdec XPLAT_6_Framework`RCTPerformMountInstructions(std::__1::vector<facebook::react::ShadowViewMutation, std::__1::allocator<facebook::react::ShadowViewMutation>> const&, RCTComponentViewRegistry*, RCTMountingTransactionObserverCoordinator&, int) + 356
    frame #14: 0x000000031a3ccc7c XPLAT_6_Framework`-[RCTMountingManager performTransaction:]::$_1::operator()(facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) const + 80
    frame #15: 0x000000031a3ccc20 XPLAT_6_Framework`decltype(std::declval<-[RCTMountingManager performTransaction:]::$_1&>()(std::declval<facebook::react::MountingTransaction const&>(), std::declval<facebook::react::SurfaceTelemetry const&>())) std::__1::__invoke[abi:ne190102]<-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&>(-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 40
    frame #16: 0x000000031a3ccbc8 XPLAT_6_Framework`void std::__1::__invoke_void_return_wrapper<void, true>::__call[abi:ne190102]<-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&>(-[RCTMountingManager performTransaction:]::$_1&, facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 40
    frame #17: 0x000000031a3ccb94 XPLAT_6_Framework`std::__1::__function::__alloc_func<-[RCTMountingManager performTransaction:]::$_1, std::__1::allocator<-[RCTMountingManager performTransaction:]::$_1>, void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)>::operator()[abi:ne190102](facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 44
    frame #18: 0x000000031a3cba1c XPLAT_6_Framework`std::__1::__function::__func<-[RCTMountingManager performTransaction:]::$_1, std::__1::allocator<-[RCTMountingManager performTransaction:]::$_1>, void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)>::operator()(facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&) + 44
    frame #20: 0x000000032f219804 XPLAT_1_Framework`std::__1::function<void (facebook::react::MountingTransaction const&, facebook::react::SurfaceTelemetry const&)>::operator()(this=0x000000016d4f0c78, __arg=0x000000016d4f0a10, __arg=0x000000016d4f0978) const at function.h:989:10
    frame #21: 0x000000032f219668 XPLAT_1_Framework`facebook::react::TelemetryController::pullTransaction(this=0x00000003f4680f00, willMount=0x000000016d4f0c98, doMount=0x000000016d4f0c78, didMount=0x000000016d4f0c58) const at TelemetryController.cpp:39:3
    frame #22: 0x000000031a3c5b28 XPLAT_6_Framework`-[RCTMountingManager performTransaction:] + 544
    frame #23: 0x000000031a3c5864 XPLAT_6_Framework`-[RCTMountingManager initiateTransaction:] + 456
    frame #24: 0x000000031a3c5240 XPLAT_6_Framework`__42-[RCTMountingManager scheduleTransaction:]_block_invoke + 308
    frame #25: 0x0000000131f81b84 BOTTOMFramework`__RCTExecuteOnMainQueue_block_invoke + 40
    frame #26: 0x000000018017c788 libdispatch.dylib`_dispatch_call_block_and_release + 24
    frame #27: 0x0000000180197278 libdispatch.dylib`_dispatch_client_callout + 12
    frame #28: 0x00000001801b2fcc libdispatch.dylib`_dispatch_main_queue_drain.cold.7 + 24
    frame #29: 0x000000018018c1c4 libdispatch.dylib`_dispatch_main_queue_drain + 1184
    frame #30: 0x000000018018bd14 libdispatch.dylib`_dispatch_main_queue_callback_4CF + 40
    frame #31: 0x0000000180427fec CoreFoundation`__CFRUNLOOP_IS_SERVICING_THE_MAIN_DISPATCH_QUEUE__ + 12
    frame #32: 0x00000001804229f8 CoreFoundation`__CFRunLoopRun + 1920
    frame #33: 0x0000000180421e3c CoreFoundation`CFRunLoopRunSpecific + 536
    frame #34: 0x0000000190f62d00 GraphicsServices`GSEventRunModal + 164
    frame #35: 0x0000000185bcec98 UIKitCore`-[UIApplication _run] + 796
    frame #36: 0x0000000185bd3064 UIKitCore`UIApplicationMain + 124
    frame #37: 0x0000000115fbf0bc PRODUCTFramework`main + 200
    frame #38: 0x00000001114293d8 dyld_sim`start_sim + 20
    frame #39: 0x0000000111506b4c dyld`start + 6000
```

Reviewed By: rubennorte

Differential Revision: D74654157

fbshipit-source-id: 9181bcd28524c71d0ca4620bd630dc0baa172386
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant