Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/4830
YogaKit is a library which allows integrating Yoga layouts directly with UIKit. It is not used by higher level libraries like ComponentKit or React Native, but is used by a smattering of surfaces and shared components in Origami Studio and Instagram. See the following search for `YogaKit/UIView+Yoga.h`.
{F1026467213}
It is not really being developed anymore, and doesn't have much of a future, so I am deprecating it in OSS, to remove after the next OSS Yoga release. This means Flipper in OSS will not be able to rely on it.
Instead of special-casing for OSS vs not, this change removes the current YogaKit integration with the layout plugin, since it sounds like we are building a new layout plugin anyway, and I'm not aware of any new surfaces being built on top of YogaKit.
Removing Yoga as a dependency from Flipper should also allow us to fixup the current OSS Flipper build, along with a whole bunch of hacks RN's open source build currently does to produce a Yoga pod compatible with both RN and Flipper.
There are probably some OSS related lockfiles that can be updated after this, for things like the FlipperKit sample app. I did not do that as part of this change, since I don't know how healthy all of that infra is or how it integrates with the offline mirror used.
Reviewed By: passy
Differential Revision: D46664918
fbshipit-source-id: 9d4dd56aa4c7f55e97ac643aa6e4deb9375e582c
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/4522
^
A codemod changed the name of `CKMountable` for the OSS ComponentKit integration, this is a breaking change as we are pinned to a specific Cocoapods version of CK.
Reviewed By: passy
Differential Revision: D43303489
fbshipit-source-id: 4d8ad472735414ca8e67a8ce4409efe84aab3e94
Summary:
^
SKDescriptorMapper owns the SKNodeDescriptor instances. SKNodeDescriptor instances should only have a weak reference to the mapper as to avoid retain cycles.
Reviewed By: passy
Differential Revision: D42673698
fbshipit-source-id: 8c98709b28fc3c711dc56c179c7c362417fa1f9d
Summary: In a previous diff D32278523 (8764da7c0b) The desktop request was changed from send to call. Call expects a response and not all code paths return a response. Most calls to set highlight are timing out.
Reviewed By: mweststrate
Differential Revision: D38074704
fbshipit-source-id: 6e85416d6b6470efaa177ad1b74420c8237366d5
Summary:
rename FLEXNetworkLib to SKFLEXNetworkLib so it doesnt clash with Stock FLEX if embedded in the app too
also 'fix' 3 warnings by adding explicit casts
Reviewed By: lblasa
Differential Revision: D35200011
fbshipit-source-id: 82bdecc5076b86958ea0cb80260584c012940045
Summary:
This is a prototype for view preview within Flipper for iOS (Android next).
If enabled, a preview of the selected element is rendered in the attribute inspector.
Changelog: Add view preview/snapshot for the Layout plugin on iOS.
Reviewed By: antonk52
Differential Revision: D34990372
fbshipit-source-id: 1984514fbf59041ad236008a8db10569c5fc5f94
Summary:
All our read/write to `identifierDict` in FLEXNetworkRecorder are done in their own thread-safe queue except one read and one write call.
Those two non-thread-safe read/write calls are causing ThreadSanitizer crashes in `react-native-macOS` when we consume flipper. By adding these calls to the `dispatch_async(self.queue` a few lines lower in the method, their access becomes thread safe as well.
Never having worked on Flipper I don't have much context on what FLEXNetworkRecorder actually does and the git history for this file shows the bug has existed since the "Initial commit" so it's unclear to me if we've purposefully not included these calls in the dispatch queue for some reason.
That said, I'd propose this as a fix as the thread sanitizing crash no longer repros for me downstream and I don't see anything immediately obvious for why this can't be in the self.queue as well.
## Changelog
Fix thread sanitizer crash in FLEXNetworkRecorder.
Pull Request resolved: https://github.com/facebook/flipper/pull/3457
Test Plan:
Running react-native-macOS with the ThreadSanitizer consistently hits this race condition on a library object in Flipper with the error below.
```
WARNING: ThreadSanitizer: race on NSMutableDictionary (pid=32575)
Read-only access of NSMutableDictionary at 0x000133ae5c60 by thread T11:
#0 -[__NSDictionaryM objectForKeyedSubscript:] <null>:130036204 (CoreFoundation:arm64+0x1897d8)
https://github.com/facebook/flipper/issues/1 __85-[FLEXNetworkRecorder recordRequestWillBeSentWithRequestID:request:redirectResponse:]_block_invoke FLEXNetworkRecorder.mm:130 (RNTester:arm64+0x1007afc48)
https://github.com/facebook/flipper/issues/2 __tsan::invoke_and_release_block(void*) <null>:130036204 (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x70514)
https://github.com/facebook/flipper/issues/3 _dispatch_client_callout <null>:130036204 (libdispatch.dylib:arm64+0x581c)
Previous modifying access of NSMutableDictionary at 0x000133ae5c60 by thread T1:
#0 -[__NSDictionaryM setObject:forKeyedSubscript:] <null>:130036204 (CoreFoundation:arm64+0x188808)
https://github.com/facebook/flipper/issues/1 -[FLEXNetworkRecorder recordRequestWillBeSentWithRequestID:request:redirectResponse:] FLEXNetworkRecorder.mm:118 (RNTester:arm64+0x1007af754)
https://github.com/facebook/flipper/issues/2 __73-[FLEXNetworkObserver(NSURLSessionTaskHelpers) URLSessionTaskWillResume:]_block_invoke FLEXNetworkObserver.mm:1690 (RNTester:arm64+0x1007adc70)
https://github.com/facebook/flipper/issues/3 __tsan::invoke_and_release_block(void*) <null>:130036204 (libclang_rt.tsan_iossim_dynamic.dylib:arm64+0x70514)
https://github.com/facebook/flipper/issues/4 _dispatch_client_callout <null>:130036204 (libdispatch.dylib:arm64+0x581c)
```
After moving the only non-thread safe read/write call into the appropriate dispatch queues I'm not longer able to repro this thread access crash after many attempts.
Reviewed By: fabiomassimo
Differential Revision: D34388079
Pulled By: lblasa
fbshipit-source-id: 2e654d601bc6a7d8d78d9a824e0aee66889b7fb9
Summary:
Flipper Network plugin uses timestamps for various usages e.g. start time of network requests, request duration, etc.
This diff changes the origin of such timestamps.
[NSDate timeIntervalSinceReferenceDate] in favour of FBMonotonicDeviceTimeGetCurrentMilliseconds().
The former uses a timestamp based on date. The latter uses the system boot time.
This translates in errors when the Flipper Desktop app tries to make sense of such timestamps.
This change also adds parity with the Android network plugin that uses System.currentTimeMillis().
The result is multiplied by 1000 as JavaScript expects a timestamp in millseconds.
Reviewed By: fabiomassimo
Differential Revision: D29029192
fbshipit-source-id: b38a4798ecf1564f5801ff3549ffeb9671fa32d6
Summary: It can now only be accessed through `RenderCore`.
Reviewed By: ivanmisuno
Differential Revision: D28532729
fbshipit-source-id: b5b97ec93c96303b2a6e4c270dfc667712086b79
Summary:
This diff makes sure that pod lib lint succeeds and the CI is green for iOS.
It got broken when I landed my changes for the refactoring of FlipperKitLayoutPlugin. It wasn't picked up by flipper-oss-ios-job as it builds sample app and sample app had all the paths to the header search path which individually FlipperKitLayoutHelpers and FlipperKitIOSDescriptors were missing.
I will add the validation of pods as a job in sandcastle when one touches FlipperKit pods, this will avoid such cases in future.
## Changelog
Pull Request resolved: https://github.com/facebook/flipper/pull/2140
Test Plan:
Imported from GitHub, without a `Test Plan:` line.
iOS jobs are green on CI in GH.
Reviewed By: passy
Differential Revision: D27417743
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 17aa4b04bf9954c4bd138261103751a245409568
Summary: Add macOS only descriptors. Currently does not support Yoga/YogaKit or accessibility features; will add those in a later diff.
Reviewed By: priteshrnandgaonkar
Differential Revision: D27332601
fbshipit-source-id: 35c93cf715f004dbf8dbf8753534f1d4f9801b4c
Summary: Add macOS dependencies and alternative classes to the libraries that FlipperKitLayoutPlugin needs to function.
Reviewed By: priteshrnandgaonkar
Differential Revision: D27328277
fbshipit-source-id: f22d1e9f6a5415cee0bae8eaada653be5f5467b3
Summary:
This diff moves the iOS descriptors and other layout helpers into its own buck target. Earlier everything was part of the FlipperKitLayoutPlugin target. When kcui, tried to add macos descriptors, we realised that FlipperKitLayoutPlugin doesn't have macos platform in it and thus he had to put #if TARGET_OS_SIMULATOR check in iOS descriptors and at some other places.
In order to make the integration easier I decided to split the Layout Plugin in following way.
```
FlipperKitLayoutPlugin
-> FlipperKitLayoutIOSDescriptors (platform set as IOS)
-> FlipperKitLayoutHelpers (used in iOS Descriptors and usefule for Macos too)
-> FlipperKitLayoutMacOSDescriptors(coming soon by kcui)(platform set as MacOS)
```
Reviewed By: kcui
Differential Revision: D27127587
fbshipit-source-id: f108ef81914297e93c886fe53dabf0a4bf11ebc1
Summary:
This diff keeps the opensource integration of CK for Flipper at the same place. It moves the code which is referred internally to a different folder under Facebook directory.
The reason we are doing this is because, CK won't be publishing any more opensource releases to Cocoapods. Thus we would like to keep the code for opensource compatible to the latest one. Internally we would refer to the CK code from Facebook directory.
Reviewed By: fabiomassimo
Differential Revision: D26047510
fbshipit-source-id: 302890bcd36d3e4c4888577d821433f58fcab5c7
Summary:
After updating the internal properties of CKInsetComponent we didn't update some KVO magic being used in Flipper which caused some crashes:
https://fb.workplace.com/groups/componentkit/permalink/4986354281413147/
Reviewed By: fabiomassimo
Differential Revision: D25946704
fbshipit-source-id: 5995cda20d12b18f7520507cb6ede897fddf2670
Summary:
This PR fixes the crash mentioned [here](https://github.com/facebook/flipper/issues/1674#issuecomment-754402609) in the https://github.com/facebook/flipper/issues/1674 . The issue was that logging `NSLog(@"%@", [self valueForKey:@"_methodDescription"]);` in the swizzled network delegate class used to cause a crash. The cause of this was the nil `methodDescription.types` sent to `class_addMethod`.
In the following change we do not add a method to the class which doesn't implement the selector, we will anyway listen for those events from the base NSURLSession class. Removing the `class_addMethod`, fixes both the issue mentioned
[here](https://github.com/facebook/flipper/issues/1674#issuecomment-754402609) in https://github.com/facebook/flipper/issues/1674.
This PR also fixes an issue where no network calls where logged in Flipper when the iOS version was 14, the reason was that the URLSessionResume task was not properly swizzled for 14.
## Changelog
- Do not add a runtime method to the delegate which doesn't implement a responder
- Fix swizzling logic of the URLSession task resume method for ios 14
Pull Request resolved: https://github.com/facebook/flipper/pull/1810
Test Plan:
- I ran the sample app and checked that the network calls are logged.
- I copy pasted the changes in RN project and verified that the issues mentioned in https://github.com/facebook/flipper/issues/1674 doesn't happen and also verified that the network calls being hit from JS and Native code gets logged in Flipper. Verified with IsolatedSwizzles.zip mentioned over [here](https://github.com/facebook/flipper/issues/1674#issuecomment-754726174). Also verified by copy pasting the code in the fresh RN project.
Reviewed By: fabiomassimo
Differential Revision: D25801510
Pulled By: mweststrate
fbshipit-source-id: 53ef574696d2abbdbfc2b6d94769327cdfa8aa2b
Summary: This adds macOS compatibility to Flipper client along with some of the standard plugins.
Reviewed By: jknoxville
Differential Revision: D24644439
fbshipit-source-id: dc15636a6ac1bf684fa1c89735f51f0e97667b62
Summary:
This should fix build failures with prod config. The symbols should only be in internal builds and not the prod ones.
```
stderr: Undefined symbols for architecture arm64:
"_OBJC_CLASS_$_SKNamed", referenced from:
...
"_OBJC_CLASS_$_SKComponentLayoutDescriptor", referenced from:
...
```
Reviewed By: rzito
Differential Revision: D24250749
fbshipit-source-id: 68c3d066a76baf4b1646f27dac0fd081bcaff41b
Summary:
This diff renames the plugin identifier of the NT State plugin to `flipper-plugin-bloks-state`.
WWW side changes are here D23991116
Distillery: D24136550
[NOTE]: LAND IT IN WEEKEND TO AVOID CLIENT AND SERVER IN AN UNSYNC STATE
Differential Revision: D23932149
fbshipit-source-id: 1d9d28f83581be48c218150fe2a5cff26e5d846e
Summary: This tripped me up for a bit. Add some docs.
Reviewed By: Andrey-Mishanin
Differential Revision: D24160934
fbshipit-source-id: a36ac6b205a9edeeb0698f44476456583146907c
Summary:
We have some "internal-only" stuff we want to put in the attribute of a layout node.
This allows us to do so a way that keeps it out of open-source and avoid the clunky subclassing.
Reviewed By: adamjernst
Differential Revision: D24162047
fbshipit-source-id: 518ab9fbf0b4274076f5b0ae1b249e197563fa7f
Summary:
Changelog: [iOS][Network] Network plugin now supports iOS 14
Network plugin stopped working for iOS 14 as reported in https://github.com/facebook/flipper/issues/1534.
The fix is based on the origin Flex network observer, as seen in https://github.com/FLEXTool/FLEX/pull/451
- NetworkPlugin supports iOS 14+
Pull Request resolved: https://github.com/facebook/flipper/pull/1543
Test Plan: Verified manually that before this fix the network plugin broken on iOS 14, and after it, it initializes correctly.
Reviewed By: passy
Differential Revision: D24136401
Pulled By: mweststrate
fbshipit-source-id: 87e0e0fa4bc927d082387d937390b1e728125753
Summary: Send data to NT/Bloks plugin instead of Bloks plugin. There are changes on the distillery side as well D23873230, which needs to land together with this diff.
Differential Revision: D23903952
fbshipit-source-id: 2b748e73116f10d69ec1cf810075882bb8fa09a6
Summary:
Related diff [Litho]: D23243009
This diff adds support for a protocol for layout messages where the type is recursively encoded as:
```
{
kind: "type",
data: ???
}
```
We check if the message adheres to the new encoding, otherwise we fall back to the old behavior. If it's the new encoding, the message is traversed recursively flattening the types to EditorValue using the type hints provided.
Reviewed By: Andrey-Mishanin
Differential Revision: D23319619
fbshipit-source-id: 79e8886f8f5a0aea4ec32938f1d5cd2fd645a297
Summary: This field is going to be removed in a subsequent version of the struct. Showing it is not that important, so let's just remove it.
Reviewed By: kevin0571
Differential Revision: D22335170
fbshipit-source-id: 0916927ee30757678f847cd0f826caa1d4a6c7cc
Summary:
`CKComponentAccessibilityContext::operator==` can be extremely expensive; it may invoke the `accessibilityLazyTextBlock` for its `CKComponentAccessibilityTextAttribute` members, and that can do a lot of string construction.
I could refactor this to make it cheaper, e.g. by migrating to a function-pointer-and-context-object approach. But the easiest thing to do is to simply remove it; I don't think it's meaningfully used.
Reviewed By: kevin0571
Differential Revision: D22322108
fbshipit-source-id: 82a0548d6dd28ec4adf2f3ba85705eabf665d100
Summary: Discovered in https://fburl.com/h6eczhr2; the highlight didn't get removed correctly. This was from [this method](https://fburl.com/diffusion/twur28gt), which must be called on main thread to be executed completely.
Reviewed By: jknoxville
Differential Revision: D21629318
fbshipit-source-id: cfc52ac755a1ddfe92e675aac1a81066ce338bd7
Summary:
This reverts D21285438 and patches some holes in the layout invalidation routines.
(I tried to use `didAddSubview:` and `willRemoveSubview:` but those are annoying for other reasons; for example, `willRemoveSubview:` can be called from within `dealloc` which is surprising. Also they still don't catch the case where subviews are being reordered.)
Reviewed By: Andrey-Mishanin
Differential Revision: D21512129
fbshipit-source-id: 1d9e8dac9333eddfae2309d446ef4de9e83220d6
Summary:
If you're going to swizzle, you have to be very careful to call the original version of the swizzled method!
The blame diff for this regression is D21285438.
In this case we would fail to call `swizzle_removeFromSuperview` if the view being removed was a child of a window. Thus the view would never be removed.
In practice, this manifested as `UITransitionView` instances being left around. These would block taps, leading to developer reports of unresponsive UI.
Reviewed By: priteshrnandgaonkar
Differential Revision: D21509692
fbshipit-source-id: e400c55232c44e9cd3f478eb2b456222c0bc6576
Summary: Similar to D21040424 and D21040426.
Reviewed By: Andrey-Mishanin
Differential Revision: D21335955
fbshipit-source-id: 5e8326915e54647c77fb241ad2ed4eaa55d0cfe2
Summary:
Similar to D21040429, we need to add data sent to Flipper desktop so that we can use to retrieve necessary data.
~~The implementation is different; storing **all** component data is needed because the plugin refers to it when asked for information. This might cause an issue because we need to store more data. However, due to the sparseness of data at a single touch, this shouldn't cause any OOM.~~
Implementation Detail:
- `FlipperKitLayoutPlugin.mm`
- When the process finishes the tree returned is trie from root node to every node that is touched
- `SKTouch.m`
- `_nodeStack` keeps track of path from root to current component
- `_treeStack` keeps track of current prefix tree (trie)
- `continueWithChildIndex` takes care of logic for `_nodeStack` and `_treeStack`
Reviewed By: Andrey-Mishanin
Differential Revision: D21335956
fbshipit-source-id: 84c0cabd7399abe50cf2deaff2b01149a1a792d5
Summary:
Currently user’s are being told to add a definition of the `FB_SONARKIT_ENABLED` macro and examples, including those in stock React Native templates, set this for the user by making use of a `post_install` hook in the user’s `Podfile`. This leads to confusion, fragile code [when a user’s project dir structure deviates from vanilla], and is ultimately not necessary as CocoaPods already has dedicated mechanisms to:
* specify build settings (through the `xcconfig` property);
* and selectively include certain pods only in certain build configurations (e.g. debug).
Finally, this PR also includes a commit [to fix the current builds](https://github.com/facebook/flipper/pull/1086/files#r418526812).
## Changelog
> Entirely control Flipper being enabled through inclusion in Podfile and optionally limiting to certain build configurations using the `:configuration` directive.
Pull Request resolved: https://github.com/facebook/flipper/pull/1086
Test Plan: I have built and ran the Sample application, as well as used this version of Flipper with a new RN app built from `master`.
Reviewed By: passy
Differential Revision: D21381828
Pulled By: priteshrnandgaonkar
fbshipit-source-id: edf6dae28eb02336a49e8230654d6186360ea8d6
