Summary:
Bumping everything that's just a patch version behind or safe-looking minor change.
Just hoping to get ahead of dependabot's next run.
Reviewed By: fabiomassimo
Differential Revision: D27367567
fbshipit-source-id: 1bf8bad02e5a9f07f5982466254f9906581230cf
Summary: Just trying to get ahead of dependabot and bump some easy dependencies all at once.
Reviewed By: fabiomassimo
Differential Revision: D27326687
fbshipit-source-id: 0c724c8e3a688aa9777945fcd46061284fd77969
Summary:
Changelog: Fixed an issue where Flipper would crash when decoding large partial requests.
The current processing of partial requests assumes that the proviced base64 string is always an utf-8 string, which is incorrect as it might contain binary data as well. This causes `atob` build in to throw errors when trying to decode binary base64 strings with the following exception:
{F538782963}
However, what is worse, if those strings were larger than ~2 mb, it would completely crash Electron rather than on the JS level, with reports like:
```
Crashed Thread: 0 CrRendererMain Dispatch queue: com.apple.main-thread
Exception Type: EXC_BAD_ACCESS (SIGSEGV)
Exception Codes: EXC_I386_GPFLT
Exception Note: EXC_CORPSE_NOTIFY
Termination Signal: Segmentation fault: 11
Termination Reason: Namespace SIGNAL, Code 0xb
Terminating Process: exc handler [85268]
Thread 0 Crashed:: CrRendererMain Dispatch queue: com.apple.main-thread
0 com.github.Electron.framework 0x000000011155b16f v8::internal::SetupIsolateDelegate::SetupHeap(v8::internal::Heap*) + 22324575
1 com.github.Electron.framework 0x000000011155e811 v8::internal::SetupIsolateDelegate::SetupHeap(v8::internal::Heap*) + 22338561
2 com.github.Electron.framework 0x00000001117e2e62 v8::internal::SetupIsolateDelegate::SetupHeap(v8::internal::Heap*) + 24978002
3 com.github.Electron.framework 0x000000010fa32660 v8::internal::ClassScope::ResolvePrivateNamesPartially() + 14944
4 com.github.Electron.framework 0x000000010fa322b5 v8::internal::ClassScope::ResolvePrivateNamesPartially() + 14005
5 com.github.Electron.framework 0x000000010fa31933 v8::internal::ClassScope::ResolvePrivateNamesPartially() + 11571
6 com.github.Electron.framework 0x000000011007ef58 v8::internal::SetupIsolateDelegate::SetupHeap(v8::internal::Heap*) + 451400
```
Reproduced this JS issue by lowering the `MAX_BODY_SIZE_IN_BYTES` in `NetworkFlipperPlugin.java` to 10KB, which causes all requests to be processed as partials.
Reproducing the the Electron crash is a lot harder, as it requires a surface that makes large, binary requests (more than a few mb), that is still intercepted by the Network layer. The best example I could find is sending large pictures or videos through a messenger for android chat. In that case it is still hard to produce due to caching though.
Fun fact, you can crash your own flipper and get the above crash by running this command:
`btoa(require("fs").readFileSync("/Users/mweststrate/Desktop/Screen Recording 2021-03-24 at 16.08.27 crop.mov", "binary"))`, where the provided file must be a few mb's large (this one is 10).
A result of fixing this issue, is that images that were send as partials can now be correctly previewed in the Network plugin again.
Reviewed By: jknoxville
Differential Revision: D27302961
fbshipit-source-id: 1ac86840f7268062bb59c789f3904537df3c51fa
Summary: This diffs refactors tsc projects structure and structure of our custom typings to allow producing typescript typings for "flipper" package. In next diffs I'm going to use the produced typings to check compatibility of plugins with certain versions of Flipper, e.g. to check whether plugin is compatible with current "stable" and "insiders" version.
Reviewed By: passy
Differential Revision: D26997158
fbshipit-source-id: a0416c7139bf08ec9d175730da4c4c2a8768eeb7
Summary: After calling "bundle-all-plugins" locally, "yarn test" is failing with obscure message, because some tests are trying to import built bundles instead of "index.tsx". This diff fixes that.
Reviewed By: passy
Differential Revision: D26986246
fbshipit-source-id: cffe988dc642e2c5d2b2028581cd162350186e0c
Summary:
It is not currently possible to create mock routes from imported network logs. This PR will provide that functionality.
See this issue for more details: https://github.com/facebook/flipper/issues/1988
## Changelog
Network plugin - create mocks from imported network logs
Pull Request resolved: https://github.com/facebook/flipper/pull/2040
Test Plan:
Use sample app to create network activity
Export network activity
Import network activity
Create mocks from imported network activity
Verify that mocks work using sample app
Reviewed By: mweststrate
Differential Revision: D26947187
Pulled By: passy
fbshipit-source-id: 5e4e0197c49bb7a8227a70e574613381815e6d30
Summary:
Mock routes may contain quite a bit of data for header values and response bodies. Currently, to turn off a mock a user must delete the mock and then go through the process of creating it when needed again. This change will allow a user to temporarily disable a mock without deleting it.
A checkbox on the Routes list is used to enable/disable mocks. As shown in this screenshot:
## Changelog
Network Plugin - disable/enable mock routes
Pull Request resolved: https://github.com/facebook/flipper/pull/1969
Test Plan:
Create mocks using sample app
Verify that mocks are working as expected
Disable the mocks
Verify that the client has been updated with mocks (minus the disabled ones) user Flipper Messages plugin
Use the sample app to send the disabled requests again and verify that they are not mocked
Reviewed By: mweststrate
Differential Revision: D26888815
Pulled By: passy
fbshipit-source-id: cb8a05a27dd69ba4d2b60085a077efe795a99a7c
Summary: When exploratory testing Flipper, I generally see quite some React key warnings. So it seems that plugin devs often miss them. This diff will configure linting more aggressively to address that (it's not fool proof, but will find the most common cases).
Reviewed By: nikoant
Differential Revision: D26722707
fbshipit-source-id: e0d2b56de2422e1147f52c8e9150d00c7ee64bd2
Summary:
Fix problems with row highlighting on mocks route list. When selecting a row, the highlight would sometimes be on the wrong row. Also, when adding routes, the routes would sometimes get added in the middle of the list instead of at the end.
These problems were caused by incorrectly referencing route rows in code. Sometimes index was used and other times the key was used. Fixed by consistently using key.
This fixes the problem described in issue https://github.com/facebook/flipper/issues/1733
## Changelog
Network Plugin - fix problems with row highlighting on mocks route list
Pull Request resolved: https://github.com/facebook/flipper/pull/1917
Test Plan:
Start with no mocks | No rows should be shown | TRUE
Add a single mock | First (and only row should be highlighted) | TRUE
Delete mock | No rows should be shown | TRUE
Add single mockAdd another mock | 2nd row should be highlighted | TRUE
Add another mock | 3rd row should be highlighted | TRUE
Add 2 more mocks and assign number to each row (5 total) | Last row should be highlighted | TRUE
Select 1st row | 1st row should be highlighted | TRUE
Delete 1st row | 1st row should be highlighed | TRUE
Select last row | last row should be highlighted | TRUE
Delete last row | last row should be deleted and new last row should be highlighted | TRUE
Highlight a middle row (row 3) | middle row should be highlighted | TRUE
Delete middle row | middle row should be deleted and last row should be in its place and should be highlighted | TRUE
Reviewed By: passy
Differential Revision: D26604455
Pulled By: mweststrate
fbshipit-source-id: f29690244e32b364983089541718f4bc75154dd1
Summary:
Bumps [js-base64](https://github.com/dankogai/js-base64) from 3.5.2 to 3.6.0.
<details>
<summary>Commits</summary>
<ul>
<li><a href="ad8897c84b"><code>ad8897c</code></a> version 3.6.0</li>
<li><a href="78016271df"><code>7801627</code></a> add isValid()</li>
<li>See full diff in <a href="https://github.com/dankogai/js-base64/compare/3.5.2...3.6.0">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Pull Request resolved: https://github.com/facebook/flipper/pull/1935
Reviewed By: mweststrate
Differential Revision: D26463175
Pulled By: passy
fbshipit-source-id: 06b223e8d89c75f5bda1e67b4e41403f7663ec7e
Summary:
Network calls are normally unique to an application as are the associated mocks. Currently, the mocks for different applications are combined together and saved to the local store. It would be better if mocks were saved (and retrieved by application).
This PR adds "appId" to the local store name to save mocks separately for each app. This is not really the ideal technique since different apps could have the same name. Android apps use packageId rather than app name (which is what appid is) to uniquely identify an app. However, package id does not seem to be available to the Flipper client so appid is used instead.
This requirement is described in this issue: https://github.com/facebook/flipper/issues/1487
Also, individual developers often have a preference for how they like to view response data (parsed or formatted). This PR saved the selected format so that the developer does not have to keep selecting it. Since this preference is not specific to an app, it is not necessary to save the preference for each app.
## Changelog
Network plugin - save mocks by app
Network plugin - save response body format preference to local storage
Pull Request resolved: https://github.com/facebook/flipper/pull/1871
Test Plan:
Install two apps (with different names)
Create mocks in each app
Restart Flipper
View the mocks for each app and verify that they are unique to the app
Reviewed By: mweststrate
Differential Revision: D26341333
Pulled By: passy
fbshipit-source-id: cc0286a9dc4e37e008672bfad7c6180f0d5675e4
Summary:
Provide a more robust technique for exporting the mocks to a file.
The current technique for exporting mocks to a file seems to fail under some scenarios. The correct format is an array of objects:
```
[
{
"requestUrl": "https://api.github.com/repos/facebook/yoga",
"requestMethod": "GET",
```
However, the following format is sometimes exported instead:
```
{
"10": {
"requestUrl": "https://demo9512366.mockable.io/SonarPost",
```
Using `Object.values` provides a more robust technique that has been successful during subsequent testing.
## Changelog
Network Plugin - new technique for exporting mocks
Pull Request resolved: https://github.com/facebook/flipper/pull/1872
Test Plan:
Create mocks in the network plugin
Export mocks
Manually examine file for correct format
Import mocks and verify that the file has been imported correctly
Reviewed By: nikoant
Differential Revision: D26172954
Pulled By: mweststrate
fbshipit-source-id: bdfa3ba7dfe656f30ef17df001fc83dd8ea18ece
Summary:
Continue with cleanup of Network plugin mock screens. This mostly consists of replacing FlexColumn, FlexRow and FlexBox with equivalent Sandy components.
Here is the new screen:
- replace text buttons with Button
- add NUX info to "Copy Highlighted Calls" button
- add message when no calls have been highlighted
- in routes list remove padding on line items
Here is the prior screen:
## Changelog
Network Plugin - Additional cleanup of UI on mock screen
Pull Request resolved: https://github.com/facebook/flipper/pull/1873
Test Plan:
Create and modify mocks
Verify that the functionality has not been affected by UI changes
Reviewed By: passy
Differential Revision: D26172915
Pulled By: mweststrate
fbshipit-source-id: f0af143d8509b53585076737832657fb095e75a6
Summary:
Made UI fixes to Network Plugin (mostly to Route screens) to continue migration to the new design framework. This consisted mostly of replacing FlexColumn and FlexRow with Layout.Container and Layout.Horizontal.
Also, contains some cosmetic changes to "Mock Network Response" page.
Here is the screenshot with UI changes:
This was the old screen for comparison:
## Changelog
Network Plugin - UI changes to continue migration to Sandy design framework
Pull Request resolved: https://github.com/facebook/flipper/pull/1864
Test Plan: Manual testing to ensure that all data still displayed with new UI changes (especially the Data and Headers info in the "Route Info" section)
Reviewed By: passy
Differential Revision: D26125656
Pulled By: mweststrate
fbshipit-source-id: a25104274ed25788e5c0738ac0a9609f2cead751
Summary:
In the network plugin, add features to import and export routes as described in issue https://github.com/facebook/flipper/issues/1651
Primary use case is that external testers (such as QA teams) would be able to create test data, convert it to mocks and save the mocks to make bug fixes easier for devs.
Here is a screenshot showing location of buttons to perform import/export (and clearing) of mock routes:
Here is another screenshot showing export dialog:
Changelog: [Network] Mock routes can now be imported and exported. Thanks bizzguy!
Pull Request resolved: https://github.com/facebook/flipper/pull/1855
Test Plan:
Performed manual testing
- create new mocks
- export mocks
- clear mocks
- import mocks
- verify that mocks still work by making GET/POST requests in sample app
Performed various permutations of above manual tests, including restarting Flipper at various points to ensure that test plan still worked. Also performed visual inspection of exported files to verify correctness.
Would be very interested in learning how to create automated tests for this functionality.
Reviewed By: passy
Differential Revision: D26072928
Pulled By: mweststrate
fbshipit-source-id: 51bd5e19e78d830b94add850d5dc9b9e45fa6fad
Summary:
The Network Plugin does not properly handle network requests that return an empty body (because of the body actually being empty or because the network call returns something like a 404 status).
Also, the creation of mocks using the "Copy Highlighted" command when the original response returns an empty body is not handled properly.
## Fix
The Android plugin now returns a response when the body length is 0.
The client plugin creates a body containing an empty string instead of null when the body is empty.
## Changelog
Fix problem in Network Plugin when original call or mock has an empty body in the response.
Pull Request resolved: https://github.com/facebook/flipper/pull/1776
Test Plan:
The following screen output for the Network Plugin shows that the call is now being handled correctly. The fields for "status", "size" and "duration" are now populated.
Also, the mock calls are properly defined and shown in yellow.
Reviewed By: mweststrate
Differential Revision: D25804212
Pulled By: passy
fbshipit-source-id: b31cc87619c604b4df76e05bca5c86554a1cabff
Summary:
Bumps [pako](https://github.com/nodeca/pako) from 1.0.11 to 2.0.2.
<details>
<summary>Changelog</summary>
<p><em>Sourced from <a href="https://github.com/nodeca/pako/blob/master/CHANGELOG.md">pako's changelog</a>.</em></p>
<blockquote>
<h2>[2.0.2] - 2020-11-19</h2>
<h3>Fixed</h3>
<ul>
<li>Fix esm build named exports.</li>
</ul>
<h2>[2.0.1] - 2020-11-17</h2>
<h3>Changed</h3>
<ul>
<li>Changed esm build <code>.js</code> => <code>.mjs</code> to fix node.js <code>import</code>.</li>
<li>Added <code>module</code> entry in package.json for some bundlers.</li>
</ul>
<h2>[2.0.0] - 2020-11-17</h2>
<h3>Changed</h3>
<ul>
<li>Removed binary strings and <code>Array</code> support.</li>
<li>Removed fallbacks for TypedArray methods (<code>.set()</code>, <code>.subarray()</code>).</li>
<li>Rewritten top-level wrappers.</li>
<li>Removed support of <code>Inflate</code> & <code>Deflate</code> instance create without <code>new</code>.</li>
<li><code>Inflate.push()</code> no longer needs second param (end is auto-detected).</li>
<li>Increased default inflate chunk size to 64K.</li>
<li>Moved exported constants to <code>.constants</code>.</li>
<li>Switched to es6. Legacy es5 builds available in <code>/dist</code>.</li>
<li>Added esm build.</li>
<li>Structure of <code>/dist</code> folder changed.</li>
<li>Upgraded build tools to modern ones.</li>
</ul>
</blockquote>
</details>
<details>
<summary>Commits</summary>
<ul>
<li><a href="45cce9f4d6"><code>45cce9f</code></a> 2.0.2 released</li>
<li><a href="b3861d9a66"><code>b3861d9</code></a> dist rebuild</li>
<li><a href="d0382badcc"><code>d0382ba</code></a> Fix esm build named exports</li>
<li><a href="8d5f9c70f8"><code>8d5f9c7</code></a> 2.0.1 released</li>
<li><a href="70ee7697ac"><code>70ee769</code></a> dist rebuild</li>
<li><a href="bd90fca738"><code>bd90fca</code></a> Add <code>module</code> entry for some bundlers</li>
<li><a href="84d6931fe8"><code>84d6931</code></a> Rename module build .js => .mjs to fix node import (<a href="https://github-redirect.dependabot.com/nodeca/pako/issues/200">https://github.com/facebook/flipper/issues/200</a>)</li>
<li><a href="52df0c510f"><code>52df0c5</code></a> 2.0.0 released</li>
<li><a href="a8faeffc94"><code>a8faeff</code></a> dist rebuild</li>
<li><a href="b4d9a94488"><code>b4d9a94</code></a> Added esm build, <a href="https://github-redirect.dependabot.com/nodeca/pako/issues/97">https://github.com/facebook/flipper/issues/97</a></li>
<li>Additional commits viewable in <a href="https://github.com/nodeca/pako/compare/1.0.11...2.0.2">compare view</a></li>
</ul>
</details>
<br />
[](https://docs.github.com/en/github/managing-security-vulnerabilities/about-dependabot-security-updates#about-compatibility-scores)
Dependabot will resolve any conflicts with this PR as long as you don't alter it yourself. You can also trigger a rebase manually by commenting `dependabot rebase`.
[//]: # (dependabot-automerge-start)
[//]: # (dependabot-automerge-end)
---
<details>
<summary>Dependabot commands and options</summary>
<br />
You can trigger Dependabot actions by commenting on this PR:
- `dependabot rebase` will rebase this PR
- `dependabot recreate` will recreate this PR, overwriting any edits that have been made to it
- `dependabot merge` will merge this PR after your CI passes on it
- `dependabot squash and merge` will squash and merge this PR after your CI passes on it
- `dependabot cancel merge` will cancel a previously requested merge and block automerging
- `dependabot reopen` will reopen this PR if it is closed
- `dependabot close` will close this PR and stop Dependabot recreating it. You can achieve the same result by closing it manually
- `dependabot ignore this major version` will close this PR and stop Dependabot creating any more for this major version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this minor version` will close this PR and stop Dependabot creating any more for this minor version (unless you reopen the PR or upgrade to it yourself)
- `dependabot ignore this dependency` will close this PR and stop Dependabot creating any more for this dependency (unless you reopen the PR or upgrade to it yourself)
</details>
Pull Request resolved: https://github.com/facebook/flipper/pull/1786
Reviewed By: passy
Differential Revision: D25664507
Pulled By: cekkaewnumchai
fbshipit-source-id: bd33a7a11ef38b54675cde31d1243742476263d9
Summary:
This diff sets all package version to "0.0.0" except of the root package and changes the bump script to only bump version in the root package. This should reduce possibility of conflicts on release diffs. Anyway we always use the same version for all of our packages, so we can only set it to the root.
Before npm publishing we will set all package versions to the same number as in the root package (we actually already do that) so there will be no differences except we won't need to bump version in more than 100 packages each release.
Reviewed By: mweststrate
Differential Revision: D25162373
fbshipit-source-id: 02fe401bee72845339c67925c130027bdaee559d
Summary: It's easier to scan the same header value of multiple requests when it's in roughly the same place for each one.
Reviewed By: mweststrate
Differential Revision: D24885172
fbshipit-source-id: 7be02903d2f9f79c8ba618e57c74169392f6244b
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
