Summary:
Some exploratory testing on all iOS and Android plugins, to see how they behave inside Sandy, and fixed some layout glitches (some were also present without Sandy)
General fixes:
* Introduced some niceties like searchbox resizing properly, and toolbars wrapping automatically in Sandy, rather than buttons becoming invisible
* Containers don't grow anymore by default, but take size of contents
* ScrollContainer child is now a Layout.Vertical. Layout.Vertical should be used as default container everywhere (e.g. Tabs, Panels) in the future
* Fixed layout issue if a split container had only 1 visible child
* DetailsSidebar now scrolls vertically by default
* Details sidebar would sometimes render content in-place rather than in the reserved area
* AppSelector dropdown and Plugin list will now properly ellipse (...) if there is not enough space
Plugin fixes:
* Long database / table names in Database plugin would break layout
Also fixes https://github.com/facebook/flipper/issues/1611
Reviewed By: passy
Differential Revision: D24454188
fbshipit-source-id: c60c867270900a1d4f28587d47067c6ec1072ede
Summary:
Changelog: [Network] Non-binary request are not properly utf-8 decoded on both iOS and Android, both when gzipped and when not gzipped
This diff fixes a long standing / ping-pong issue regarding network decoding differences between
* iOS vs Android
* binary vs utf-8
* gzipped vs uncompressed
The changes aren't too big, but the underlying investigating is :)
The primary contribution to this diff is:
First, adding test cases for know problematic cases. This is done by grabbing the messages that are send from the flipper client to flipper using the flipper messages plugin. This is the base64 data that is stored in the `.txt` files. Beyond that, for all tests public endpoints are used, so that we can both get a hold of the raw original files, and how we expect them to be displayed in flipper.
For testing a simple RN app was build, with a button that fires a bunch requests. The first 3 are captured in unit tests, the last one is not idempotent, but a case reported in #1466, so just left it there as manual verification.
```
const fetchData = async () => {
await fetch(
'https://raw.githubusercontent.com/SangKa/MobX-Docs-CN/master/docs/donating.md',
{
headers: {
'Accept-Encoding': 'identity', // signals that we don't want gzip
},
},
);
await fetch('https://reactnative.dev/img/tiny_logo.png?x=' + Math.random());
await fetch(
'https://raw.githubusercontent.com/SangKa/MobX-Docs-CN/master/docs/donating.md',
);
await fetch(
'https://ex.ke.com/sdk/recommend/html/100001314?hdicCityId=110000¶mMap[source]=&id=100001314&mediumId=100000037&elementId=&resblockId=1111027381003&templateConfig=%5Bobject%20Object%5D&fbExpoId=346620976471638017&fbQueryId=&required400=true&unique=1111027381003&parentSceneId=',
);
};
```
The second contribution of this diff is that it doesn't use weird URLencoder hacks to convert base64 to utf8, but rather a proper library. The problem with our original solution, using `atob` is that it converts to ASCII, not to utf-8, which is the source of the original bugs. See for more background on this: https://www.npmjs.com/package/js-base64#decode-vs-atob-and-encode-vs-btoa-
Solves:
https://github.com/facebook/flipper/issues/1466https://github.com/facebook/flipper/pull/1541https://github.com/facebook/flipper/issues/1458
Supersedes D23837750
Future work: we don't inspect the `content-type=xxx;charset` header yet, which we should do for less common encodings, to make sure that they get displayed correctly as well
Future work: in feature like copy data and curl, we always call decode body, without check if we are actually dealing with non-binary data. Probably it is better to keep binary data in base64, rather than decoding it, as that will assume the data is an utf-8 string, which might fail.
An assumption in these changes is that binary data is never gzipped, which is generally correct; gzip is not applied by webserver to things like images, as it would increase, not decrease their size, and waste a lot of computation power.
Reviewed By: cekkaewnumchai
Differential Revision: D23403095
fbshipit-source-id: 5099cc4a7503f0f63bd10585dc6590ba893f3dde
Summary:
I noticed that after the typescript upgrade, I got several weird positives from ESLint (like unused parameters in a type definition, which are obviously always unused, e.g. `type onClick = (e: Event) => void`). After some investigation, it turned out these warnings are generated by eslint, but that those rules should be performaned by typescript/eslint instead. For future reference to which rules this applies:
https://github.com/typescript-eslint/typescript-eslint/blob/master/packages/eslint-plugin/README.md#extension-rules
Updated the config, and while at it, fixed all warnings in our codebase, except for `react-hooks/exhaustive-deps` warnings, since those require semantic changes.
This reduces the amount of eslint warnings from 86 to 39.
Reviewed By: passy
Differential Revision: D23905630
fbshipit-source-id: 0557708fd9ec6b17840a3c191e7d3baf225bdf23
Summary:
This diff tries to address T74467181, where Flipper (Electron) crash hard with a segfault. Although I failed to find the root issue, I noticed that this typically happened when switching to the network plugin after a long time.
Switching the network plugin causes all rows to be rebuild, and during the process all request and response bodies are deserialized which can take very long and fully blocks Flipper making it totally unresponsive.
This diff fixes that issue, by making sure the lately added lazy evaluation of copyText is used, and that requests aren't deserialized during row generation, which is only needed for full body search purposes, by making that lazily as well.
While at it fixed D21929666 (which I never finished) as well, which is a Sandy prerequisite, since it coupled the generic search table to hardcoded networking concepts like request and response. "body" search, has now been rebranded "contents" search. That is generic and makes sense in both the network and qpl plugin. Probably will make these labelings better customisable when revisiting the grids in Sandy
N.B. I thought the issue might maybe that during the blocking process the garbage collector can't run, and the process would OOM. But that doesn't seem the case (or at least not without some other factor contribution as well), as in a quick test I can trivally allocate 30 GB of memory (making the system swap), but still the process runs stably. So even with this diff I can't satisfactory explain the crash, but at least it avoids a common circumstance in which they happen, and it significantly improves the user experience.
changelog: [Network] Fixed issue where Flipper would hang for seconds or even crash when opening the Network plugin
Reviewed By: jknoxville
Differential Revision: D23599338
fbshipit-source-id: 52164fe6997b879c91907e0afe42e08ca3f315b4
Summary: In the attached task an IPv6 address ended up in the URL send from IG. Since that URL couldn't be parsed, it crashed the network plugin. This change makes sure the plugin doesn't crash on invalid urls.
Reviewed By: cekkaewnumchai
Differential Revision: D23344503
fbshipit-source-id: c7ac2068e407a764d59e632bef1be7c4239c8c8a
Summary:
Images in the network plugin are rarely displayed in the network plugin, as it tries to use the public url to preview it. However, that won't if the endpoint is behind authentication, idempotent, etc. This diff changes the behavior to instead send the network body to flipper and use that to preview.
Changelog: [Network] Fixed image preview
Reviewed By: jknoxville, passy
Differential Revision: D23370743
fbshipit-source-id: 0070e9e38c10a5761b9f7190467e26f01a7b2471
Summary:
This is a replacement for PR https://github.com/facebook/flipper/pull/1486 which had the wrong username
When the network plugin is loaded, the route table in the device is empty. It needs to be populated with whatever routes have already been created and saved in local storage. Otherwise, the user would need to modify the routes to force an update.
Issue is described here - https://github.com/facebook/flipper/issues/1476
## Changelog
Routes updated in device when plugin is initialized
Pull Request resolved: https://github.com/facebook/flipper/pull/1491
Test Plan:
1. Create a mock for the get request in the sample Android app
2. Kill the app
3. Start the app
4. Issue the get request in the app
5. Verify that the request is mocked in the Network plugin

Reviewed By: passy
Differential Revision: D23292355
Pulled By: mweststrate
fbshipit-source-id: 2fe16e9067a627cae02a4b1db422952d364fd036
Summary:
There's a bug in the network inspector.
Messages come in in batches for performance reasons.
These batches can include both requests and responses, but the code assumes only one or the other.
This fixes it to make it not mutually exclusive.
This bug only affects row building in the table, so when you click on the row, you can still see the response and everything.
Reviewed By: cekkaewnumchai
Differential Revision: D23102575
fbshipit-source-id: 47e8c6b0f1c9cf0d5860b6f349a7d9fe225c73ae
Summary:
It's common for responses to be completely missing in the network inspector. This is because they are larger than can be serialized in one go on some devices, so we drop all messages larger than 1MB.
This changes the android client to send large responses in individually serialized batches. This way we avoid running out of memory and can still send arbitrarily large payloads.
Changelog: Android network inspector can now handle responses large than 1MB.
Reviewed By: passy
Differential Revision: D22999905
fbshipit-source-id: ff4eb8fa72a7e42ea90d12ffe0f20c6d1e58b7e5
Summary:
This diff adds several improvements to displaying requests / responses in the network plugin
1. If there is no formatter rendering the data, the data is rendered 'raw'
2. For binary data, `(binary data)` text is printed, rather than an empty box
3. For request that have an empty request / response, `(empty)` is printed, rather than an empty box
4. If a formatter is applied, we show which formatter was used, which makes it easier to debug / spot / report issues
5. If the graphql formatter can't parse the data because it is truncated, it won't return anything, so that it falls back to the next formatter (urlencoder) to take care of the presentation
Changelog: [Network plugin] Improved presentation of request / response bodies and fixed issues where they would sometimes not be displayed.
Reviewed By: jknoxville
Differential Revision: D22865373
fbshipit-source-id: 912d2f27269a4c9edbf62f2039d46ccf90a008af
Summary:
This was originally done in https://github.com/facebook/flipper/pull/377 to support chinese characters, but it's not clear how it works, or what problem specifically it is trying to solve.
It's causing some problems where valid responses are failing to be "decoded", so I'm removing it.
Reviewed By: mweststrate
Differential Revision: D22866879
fbshipit-source-id: a19a57b0ddba2b9f434eb3c37e6b92da1dfbef01
Summary:
This adds support for handling incoming deeplinks in a Sandy plugin, which can be done by using a `client.onDeepLink(deepLink => { } )` listener
Also generalized deeplinks to not just support strings, but also richer objects, which is beneficial to plugin to plugin linking.
Reviewed By: jknoxville
Differential Revision: D22524749
fbshipit-source-id: 2cbe8d52f6eac91a1c1c8c8494706952920b9181
Summary:
Trying to get our OSS report green and lodash is currently flagged as a security issue on GH.
Manually merged the different PRs on GitHub together.
Reviewed By: jonathoma
Differential Revision: D22599614
fbshipit-source-id: ea4c9abf21aade14cff9338b78b764b181193227
Summary: Removed back "prepack" script from every plugin package to keep it simple. Instead we will use `build-plugin` command defined in the root package.json (see next diff in the stack).
Reviewed By: mweststrate
Differential Revision: D22160252
fbshipit-source-id: cffb5df65b89df3fe390c051da0df797b3d16d2d
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/1267
Bumped versions of all plugins to match current Flipper version 0.46.0.
Reviewed By: mweststrate
Differential Revision: D22042959
fbshipit-source-id: 37c169bfd1b90debb8f94c9465a345a015524158
Summary: All the plugins migrated to spec v2 to allow packaging/publishing them independently from Flipper releases.
Reviewed By: passy
Differential Revision: D22041384
fbshipit-source-id: 23bfaf724f771a57bd628b9ea1c4d37846534a93
Summary:
See previous diffs, same change as with analytics, don't stringify when creating the rows, but rather provide a closure to do that lazily, which reduces CPU (and mem) usage.
Note that this implicitly assumes the captures variables are immutable, as otherwise the semantics would change. But than again, if those variables are changed in the future, copyText will reflect their latest rather than initial state, which is better anyway.
Reviewed By: nikoant
Differential Revision: D21931748
fbshipit-source-id: 62325dd25953bab3a4e2e9a0d5dea3b3a7787bae
Summary:
Implemented json schema for flipper plugin package.json and used it for validation in "flipper-pkg lint" command.
Nice thing about json schema is that it not only allows to validate json, but also can be referenced using "$schema" property in json so IDEs like VSCode can find it and use for code completion, validation and to show properties documentation. I'm going to deploy the schema as a part of documentation website so it can be referenced as https://fbflipper.com/schemas/plugin-package/v2.json.
Also the "$schema" field can be used instead of "specVersion" to determine the specification according to which the plugin is defined. E.g., if specification version 3 would be created, it will be described in schema https://fbflipper.com/schemas/plugin-package/v3.json, etc.
Reviewed By: passy
Differential Revision: D21228294
fbshipit-source-id: f21351e584ef936a7d6b314436448489691f83a6
Summary:
Added "id" field to Flipper plugin manifest which is used to match native and desktop plugin parts. Before that, "name" field was used both as npm package name and as plugin id.
The problem is that currently there are a lot of plugins which has invalid values in "name", e.g. not starting with "flipper-package-", or containing upper cased letters.
Simple renaming of "name" field can be very problematic, so we need a new field to avoid any breaking changes and keep historical analytics data which is also bound to plugin id.
Reviewed By: mweststrate
Differential Revision: D21129689
fbshipit-source-id: efd143c82a6a802cc0b5438fd3f509bd99aded0e
Summary:
Added versioning for plugin format.
The first version is where "main" points to source code entry and plugins are bundled by Flipper in run-time on loading them.
The second version is where "main" points to the already existing bundle and Flipper just loads it without bundling. The plugins of version 2 must be bundled using "flipper-pkg" tool before publishing.
Changelog: Support new packaging format for plugins.
Reviewed By: mweststrate
Differential Revision: D21074173
fbshipit-source-id: 7b70250e48e5bd5d359c96149fb5b14e67783c4d
Summary:
Pull Request resolved: https://github.com/facebook/flipper/pull/969
Added all public plugins as workspaces to the root package.json. This means all these plugins will use the single root yarn.lock and installation of their dependencies will be faster. This also means that plugins can declare dependencies to other local packages included into workspaces and they will be symlinked automatically.
Changelog: Internals: plugins added as "yarn workspaces" into the root package.json to simplify dependency management between them
Reviewed By: mweststrate
Differential Revision: D20805231
fbshipit-source-id: e85c62d3195d1ea3c5c60def6ca12318a2b53466
Summary:
Quick notes:
- This looks worse than it is. It adds mandatory parentheses to single argument lambdas. Lots of outrage on Twitter about it, personally I'm {emoji:1f937_200d_2642} about it.
- Space before function, e.g. `a = function ()` is now enforced. I like this because both were fine before.
- I added `eslint-config-prettier` to the config because otherwise a ton of rules conflict with eslint itself.
Close https://github.com/facebook/flipper/pull/915
Reviewed By: jknoxville
Differential Revision: D20594929
fbshipit-source-id: ca1c65376b90e009550dd6d1f4e0831d32cbff03
Summary:
The network plugin warns about network requests that cannot be properly deflated if they are big and binary. Not sure yet why that is the case and if that is something that should be addressed (planned T63909985 for that), but if the body is big and binary it causes problems for our logging.
While testing I had some requests that where 45m large, and Electron literally hang for a few minutes before recovering. Failed to capture that, but the test plan shows smaller cases of the problem
Reviewed By: jknoxville
Differential Revision: D20560083
fbshipit-source-id: 324eb180b203dd585814dba5c94373d8daee5dde
Summary:
1) moved "sonar/desktop/src" to "sonar/desktop/app/src", so "app" is now a separate package containing the core Flipper app code
2) Configured yarn workspaces with the root in "sonar/desktop": app, static, pkg, doctor, headless-tests. Plugins are not included for now, I plan to do this later.
Reviewed By: jknoxville
Differential Revision: D20535782
fbshipit-source-id: 600b2301960f37c7d72166e0d04eba462bec9fc1