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:
This is an automated PR to update the Podfile.lock.
- Make sure that the Podfile.lock contains latest FlipperKit and Flipper pod versions.
- Also make sure that all the dependencies are updated to the latest one.
- This is auto-generated by [create-pull-request](https://github.com/peter-evans/create-pull-request)
Pull Request resolved: https://github.com/facebook/flipper/pull/1141
Reviewed By: passy
Differential Revision: D21440678
Pulled By: priteshrnandgaonkar
fbshipit-source-id: 616c083237b23807d152db59a7a223f53bc45028
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
Summary:
This is an automated PR to update the Podfile.lock.
- Make sure that the Podfile.lock contains latest FlipperKit and Flipper pod versions.
- Also make sure that all the dependencies are updated to the latest one.
- This is auto-generated by [create-pull-request][1]
[1]: https://github.com/peter-evans/create-pull-request
Pull Request resolved: https://github.com/facebook/flipper/pull/1110
Reviewed By: priteshrnandgaonkar
Differential Revision: D21399344
Pulled By: passy
fbshipit-source-id: ee3435d19593c93566737bbe16252a8d4863fffa
Summary:
Before this diff the nodes were not invalidated properly when the new view got added in the hierarchy, due to this there was following bug.
https://our.intern.facebook.com/intern/px/p/15RSP
Reviewed By: Andrey-Mishanin
Differential Revision: D21285438
fbshipit-source-id: b72aa93856688b31296ae1df4f15e128037aa1ca
Summary: This diff commits Podile.lock, once this diff gets landed I will add a github action to automatically raise a PR with the updated Podfile.lock
Reviewed By: cekkaewnumchai
Differential Revision: D21348940
fbshipit-source-id: e3bcdb8699442aa8d3092d9517c332eeb9c02981
Summary:
Add support for io_uring based async read/recvmsg
(Note: this ignores all push blocking failures!)
Reviewed By: kevin-vigor
Differential Revision: D21208891
fbshipit-source-id: 21b3b5e0f201e982ecb50a284d03ab53413ec3e3
Summary: Added in D14209157, but the JavaScript no longer ever calls this method.
Reviewed By: jknoxville
Differential Revision: D21290792
fbshipit-source-id: df1969d83f0dc096a24977c15c27100d2f2bdfc0
Summary:
Background for this diff: https://fb.quip.com/KqEfAlKYlgme
Some plugins don't respect that stuff (livefeed and graphql), but for others it seems to work fine.
This is just a PoC, there are some present bugs concerning the combination of selecting and bg plugins
Questions to investigate:
- [x] make sure that LiveFeed and GraphQL disconnect properly. There might be more plugins that need that
- [x] verifiy that we don't loose one of the original goals of background plugins, e.g. QPL collecting and sending data from device start. Does this still work as intended after this change?
- [x] how can we observe / measure improvements? Are dev builds more responsive after this? Is the layout inspector smoother for example because no QPL plugins are interweaved?
- [x] how is forward and backward compatibility?
- If Flipper is updated, but device not: No change I think, as getBackgroundPlugins() will return an empty set, and background plugins are initiated as usual, so old behavior
- If device is updated, but Flipper not, background plugins won't be started until they are selected. This is a degradation, but hopefully explainable.
- [x] Verify QPL buffer is not unbounded
- [x] Share architecutre changes with team
For Graphql updates: D20943455
Added runtime stats to monitor network traffic (sadly had to redo that since scuba couldn't handle the data format used at first, so probably will hold of landing this diff a week to make sure we can see some effects)
Follow up work:
[x] wait until we released the stat tracking before we release this, to be able to measure the effect?
[x] make sure graphql fix lands
[ ] use side effects abstraction
[ ] fix other background plugins (android only) or fix it in a generic way:
{F234394286}
Changelog: Background plugins will no longer receive a Flipper connection if they are disabled. This should significantly reduce the overall load of Flipper both on the device and desktop when unused plugins are disabled used, which could otherwise generate 10MB/s of network traffic certain scenarios. All plugins *should* be able to handle to this gracefully, but since this is quite a fundamental change, reach out to the Flipper team when in doubt!
Reviewed By: jknoxville
Differential Revision: D20942453
fbshipit-source-id: b699199cb95c1b3e4c36e026b6dfaee7d1652e1f
Summary: Currently subdescriptors are *always* rendered. Allow them to return `nil` to signal that they don't need to be rendered.
Reviewed By: cuva
Differential Revision: D21157249
fbshipit-source-id: 68a83424efc50723e1ec71c069feef8e10037671
Summary:
Before this diff, Flipper showed *leaf* views created by ComponentKit, but not any intermediate views. Now we show both.
A new node type `SKComponentMountedView` is used for this purpose. Its descriptor `SKComponentMountedViewDescriptor` mostly delegates to its view's descriptor, but redirects back into ComponentKit for children.
Reviewed By: Andrey-Mishanin
Differential Revision: D21130997
fbshipit-source-id: b3c12ea7cc1200962b3ba7c269c48d68b1809948
Summary:
This change makes it possible to remove preferences. I also added a `Delete` context menu option to `DataInspector` because I needed it to implement this feature. passy confirmed that it makes sense to add this because delete is a common action.
Fixes https://github.com/facebook/flipper/issues/451
Pull Request resolved: https://github.com/facebook/flipper/pull/1018
Reviewed By: jknoxville
Differential Revision: D21086308
Pulled By: passy
fbshipit-source-id: 551ff0908d5e6c93f58d6012b42e1ee3531de997
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/1016
YogaKit's version is compatible recent version of swift and also before the last release its swift version was not mentioned, which caused issues, but now there is no need to set the swift version.
Reviewed By: passy
Differential Revision: D21054723
fbshipit-source-id: 2210cf4beab86088533302028091e0bc44b9d232
Summary: Component classes do not reflect the source of the component anymore.
Reviewed By: fabiomassimo
Differential Revision: D20595754
fbshipit-source-id: 645a63f78ee6aaaf75ac0c1e08bf67229a3f906b
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/992
Right now our sample app's fail to build when built against "Generic iOS Device", but it built successfully when built against simulator. Reason being all the simulators are 64 bit's, but when built against generic iOS device type, it didn't work for all the architecture as our Flipper and Flipper-Folly pod had 64bit architecture in their settings. But as soon as you build Flipper-Folly for standard architecture, RCU.cpp fails to build as that file is incompatible for lower standard architecture. Got the following error
{F233400670}
But, we do not need that file of Folly to build Flipper and RSocket. Thus in the podfile I have excluded it from its source. Also along with it I upgraded both Folly and RSocket to the latest releases.
Even with this changes i got one more problem, our openssl static library is not bitcode enabled for arm architecture, this error popped up when built against "Generic iOS Device". Right now I have disabled bitcode, the proper fix of this would be to find a dependency of openssl which is bitcode enabled. Its really hard to find the proper cocoapod dependency of openssl which is bitcode enabled. But disabling bitcode is not a big ask, also people will face this error only when they try to publish flipper in their release.
I discovered this problem from an issue posted in [RN](https://github.com/react-native-community/upgrade-support/issues/35), it also takes care of this issue.
Reviewed By: passy
Differential Revision: D20897590
fbshipit-source-id: 8c79d239572bb7efe2d65b2a7f1cfe8c608c1df4
Summary:
Updates the instructions to integrate iOS pods for the case with the usage of `use_frameworks!` for cocoapods 1.9. Also changed our podfile for Tutorial app and add travis test for the same, so that in future if there are any further changes with the API in new releases of cocoapods, we can catch it.
## Changelog
- Added travis test for iOS Tutorial app
- Updated the getting started guide for iOS
Pull Request resolved: https://github.com/facebook/flipper/pull/892
Test Plan: Travis test passed and also tested that tutorial app builds with cocoapods 1.9
Reviewed By: mweststrate
Differential Revision: D20587989
Pulled By: priteshrnandgaonkar
fbshipit-source-id: b297e6b1298a20a9279ad6414e9d099917876fb1
Summary:
Original commit changeset: 41028c11da6c
I will use mitmproxy for offline support, but till then lets back out the diff and make our tests work for all cases
Reviewed By: passy
Differential Revision: D20514538
fbshipit-source-id: c081baba0a0c7189ae862a66b6116f26b1401177
Summary: It took me a few tries to understand what this was for.
Reviewed By: jknoxville
Differential Revision: D20462208
fbshipit-source-id: f6dac7836409c8d4ec1ffb90a74f632624fb68f7
Summary:
- Avoid holding lock while calling out to `send:withParams:`; it's hard to reason about whether we could trigger deadlock.
- Remove unnecessary `lastInvalidateMessage` ivar; we already ensure that we send at most one invalidate batch per 500ms by using `invalidateMessageQueued`.
- Misc code style items
Reviewed By: Andrey-Mishanin
Differential Revision: D20462193
fbshipit-source-id: 80f61e5a7ce5021e16ebc19a2ec40adfc46f9b92
Summary: All current implementations of `CKComponentHostingViewProtocol` *contain* a `CKInspectableView`, so there is no need for the hosting view itself to conform. This also simplifies the Flipper plugin.
Reviewed By: d16r
Differential Revision: D20457822
fbshipit-source-id: 472f80f5bb2ee507862487d076cfb0e3de6416fa
Summary: Change compiler flag "-Wno-unguarded-availability" to "-Wunguarded-availability" in order to make build time safety check for unsafe newly introduced api without guarding it with available conditional.
Reviewed By: priteshrnandgaonkar
Differential Revision: D20335903
fbshipit-source-id: b4b0e492a9244233f1bc3b5ba2a63c6415c92bb4
Summary: Adding the new "Identity" section to CK components' description.
Reviewed By: cuva
Differential Revision: D19948738
fbshipit-source-id: cbd9bc9c77b6f6503e10cfc75581ef4b94dd0247
Summary:
This diff updates the podfile.lock and also updates all the dependencies in the lfs. Actually we don't need all the dependencies to be reuploaded in the lfs, but current script packs everythin in Pods folder and uploads it, I will upload the logic to look for the diff and only upload the changed dependencies.Also we can merge this logic in our release script. I will put this up in later diffs.
Right now the CK folks are stuck due to the release of CK dependency and their OSS job is failing and this should fix the failing oss-ios job on diff D19948738
Reviewed By: Andrey-Mishanin
Differential Revision: D20378076
fbshipit-source-id: 56ed996cd75fba77a15e7264f9e5c27b262f00d2
Summary:
React Native v0.62.0’s template still uses iOS 9 as deployment target, bumping it to 10 this late in the release cycle is probably not a good idea, so instead I made this tiny change to make it iOS 9 compatible again.
⚠️ I made this change on top of the `v0.32.2` **tag**, as `master` was giving me a build failure and in any case it would be better to release _just_ this change as a patch release so the RN `v0.62.0-rc.3` release can go out without having to test Flipper as thoroughly again.
## Changelog
Make FlipperKit compatible with iOS 9 again.
Pull Request resolved: https://github.com/facebook/flipper/pull/874
Test Plan:
- `pod install` with a Podfile that has iOS 9 as its deployment target passes again.
- Building the Flipper Sample works.
- Building with a RN application created with the `v0.62.0-rc.3` template works.
Reviewed By: priteshrnandgaonkar
Differential Revision: D20307073
Pulled By: passy
fbshipit-source-id: 0dd02dfb810b7382c52ca81b8f1322f807fb3f29
Summary:
This diff adds the ability to run iOS tests without doing pod install in sandcastle. For this, the repo will already have the dependencies archived and checked into the repo. For this I have already added the script, `recreate_offline_mirrors` which takes the first argument, which is the sample app's name, in our case it will be `Sample` and `SampleSwift`. There is one more script `prepare_pods` which untars the dependencies and copies it into the Pods folders.
Reason we are moving away from using `pod install` is that internet is unreliable in sandcastle and there have been many instances that the job fails due to flaky internet.
Reviewed By: passy
Differential Revision: D20136440
fbshipit-source-id: 41028c11da6c66b484f36c7d1090ac7ffd847ec2
Summary:
Original diff broke OSS flipper. Need a new OSS release of CK first
Original commit changeset: 3e7564b25610
Reviewed By: kfirapps
Differential Revision: D20304743
fbshipit-source-id: 08a56359a42bc56b576d212e7cf642197a064076
Summary: Use `component.className` in sonar for the layout inspector.
Reviewed By: kfirapps
Differential Revision: D20184486
fbshipit-source-id: 3e7564b2561016ee59f3b1fc9d21313e068bacb3
Summary:
The target selector was broken on iOS. The overlay view which has the gesture recognizer, was never added to the window, due to which the gestures were not registered and the feature broke.
This diff adds the overlay view in the window object as the subview and then discards it in its view descriptor as otherwise we will capture all our touches in this view.
This was the most popular bug in our research trip and almost everyone reported it.
Reviewed By: fabiomassimo
Differential Revision: D20225594
fbshipit-source-id: af4041859d7e662152b2575d1eb258dd0c2d990e
