Summary:
Adding a feature to Flipper's Logs plugin where:
1) you search for something,
2) click on a line among the filtered search results,
3) press control,
4) get taken back to unfiltered list of all messages, centered on your selected line
This is to help debugging where the user may add a print statement but the error happens after it, and it's difficult to catch without a lot of scrolling.
Reviewed By: mweststrate
Differential Revision: D33446285
fbshipit-source-id: 19aa472a12de074e561dbe37b44821fc29bf5c91
Summary: When building for Mac Catalyst, it mostly appears as if it's targeting iOS (`TARGET_OS_OSX` is `0`) and the behavior should be aligned with iOS Simulator builds.
Reviewed By: lblasa
Differential Revision: D34413681
fbshipit-source-id: 1e56bbb3f16f8cd78e77771ff641c5cfcbc49955
Summary:
^
Changes include:
- C++ WebSocket integration
- Explicit asio namespace usage as namespace asio = websocketpp::lib::asio; this way we don't care if boost::asio or just asio is used in the end.
Reviewed By: javache
Differential Revision: D34388770
fbshipit-source-id: d0b3ee8ac687751ab1b93d483729eb2baccb8687
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:
allow-large-files
During decapitation the style guide was accidentally removed. In this diff we bring it back and embed it into our docs.
The only caveat is that the fonts have slightly changes because we included antd.css. It does not change too much from my point of view, but I would love to hear from the team.
Reviewed By: jknoxville
Differential Revision: D34339758
fbshipit-source-id: 10d347bc805f9314ae717de483bf8b766000280f
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/3473
This diff is the first one which addresses https://github.com/facebook/flipper/issues/3320.
In this diff we are making a part of the code used for internal Flipper plugin distribution in Meta also available publicly for re-using in other orgs.
Some explanation on how plugin installation and updates is designed now:
1) We periodically poll for plugins available for download. API for retrieving available plugins list is abstracted and will be different between public and fb versions, however all other logic is re-used.
2) In addition to "Enabled" and "Disabled" plugins in the left panel Flipper shows "Detected in App" list. Plugins in this list are those which are known compatible with the currently selected device/app, but not yet installed.
3) User can install any of "Detected in App" plugins by clicking to "Download and install" button near them in the left panel similarly to enabling plugins in "Disabled" list.
4) If we detect that for some installed plugin we have a newer version available for download - we download it silently and store on disk.
5) If the plugin for which we have new downloaded version is disabled - we update it silently without any notifications by loading new version from the disk and unloading the previous version from cache.
6) If the plugin for which we have new downloaded version is enabled then we avoid updating it automatically (because we need to reset plugin state in such case) and instead show notification on top of the plugin and ask user to reload it to apply new version. On reloading we reset the plugin state.
7) On Flipper startup we always update all plugins to their latest versions available on the disk.
Reviewed By: aigoncharov
Differential Revision: D34380308
fbshipit-source-id: a94d724e42aa5ef78445af266fcd4c424226a703
Summary:
This is just refactoring in preparation to open-sourcing internal plugin distribution code to make it available for other orgs so they can distribute their internal plugins. See other diffs in the same stack.
This diff moves recommended plugins handling from `pluginMarketplace` which will be the same for fb-internal and OS versions into `pluginMarketplaceAPI` which will differ for fb-internal and OS versions. This will make it possible for other orgs to define their own "recommended" plugins which then will be automatically installed/enabled for new users.
Reviewed By: aigoncharov
Differential Revision: D34379981
fbshipit-source-id: 5c3a4efb6d0171256cf508f9005d914d7332e14f
Summary:
^
LogView is raising this up but I don't think there's an actionable item from our side. If a client doesn't have the right arguments on the query string then we effectively are unable to construct a valid query.
All our clients do this correctly, but there may be instances that either a browser or another process is 'trying' to connect to Flipper even if unintentionally. This behaviour I've observed in the past.
Changelog: Log 'Unable to extract the client query from the request URL' as warning
Reviewed By: passy
Differential Revision: D34340068
fbshipit-source-id: f5fc36a9803a83d6662b6383589bc0aa99774798
Summary:
This diff has been automatically generated by the inpage editor.
If you want to update this diff, go through the preview link that would be attached to the test plan.
Please ensure you are editing the same page that was used to create this diff.
Reviewed By: nikoant
Differential Revision: D34249537
fbshipit-source-id: cc64c219d3400633af7bbcb5ab002c13dfb83899
Summary:
Done using
```
./gradlew wrapper --gradle-version=7.4 --distribution-type=all
```
Waiting for CI result to check if this also addresses the build problem.
Note for reviewers: This is generated. Scanning for Bad Things is appreciated but you don't need to carefully read every line.
Depends on https://github.com/facebook/flipper/issues/3436.
Pull Request resolved: https://github.com/facebook/flipper/pull/3437
Test Plan: The recently added test step for verifying that this doesn't regress our APK creation is passing: https://github.com/facebook/flipper/runs/5188576639?check_suite_focus=true
Reviewed By: lblasa
Differential Revision: D34218046
Pulled By: passy
fbshipit-source-id: 20d3c543db8f1c12f996977d0bb34d62ea5bcd0b
Summary:
Dynamic information means we can't deduplicate on the backend.
Logging the serial as a warning instead.
In general, I'm not convinced this is a good error to begin with
as it seems expected that devices can disappear on disconnect
but getting a better count should help to make that decision.
Reviewed By: aigoncharov
Differential Revision: D34247723
fbshipit-source-id: ace3c32d2370433dcca2debbea3a2c5d7a2ecb57
