Summary:
Reasons:
* It is more clear and readable;
* It is more semantical;
* It allows us to add some magic (and complexity, to be fair) to the RCTExecuteOnUIManagerQueue. (See next diffs in the stack.)
Reviewed By: javache
Differential Revision: D5935466
fbshipit-source-id: aeb18d6e11c047eb19182a656da581b6ce073602
Summary:
This fixes [#15801](https://github.com/facebook/react-native/issues/15801)
We ran into a strange crash on iOS (debug only). After removing the clutter I was able to reproduce it in a tiny app. You can check it out [here.](https://github.com/simonracz/textinput_stress)
The UI in JS and native are not always in sync (which is okay). Due to this, a native view might call back into JS, which is no longer present in the shadow view hierarchy there. I think this should be also okay.
TextInput in some cases calls into [setIntrinsicContentView](6d67e2dbbc/React/Modules/RCTUIManager.m (L382)), where it triggers an overly enthusiastic `NSAssert` and crashes the app.
Check out [textinput_stress](https://github.com/simonracz/textinput_stress)
Rotate the simulator a few times to see the crash or the lack of crash.
Closes https://github.com/facebook/react-native/pull/16170
Differential Revision: D5959776
Pulled By: shergin
fbshipit-source-id: f39f5a3f1d86b330ecf7cbccd90871bc01fd69d9
Summary:
This is required for D5874536, wherein I'll be introducing direction-aware props for borders.
When a view's border changes due to a direction update, only the frames of its children update. Therefore, only the children `UIView`s get a chance to be re-rendered. This is incorrect because the view that's had its borders changed also needs to re-render. So, I keep a track of the layout direction in a property on all shadow views. Then, when I update that prop within `applyLayoutNode`, I push shadow views into the `viewsWithNewFrames` set.
Reviewed By: mmmulani
Differential Revision: D5944488
fbshipit-source-id: 3f23e9973f3555612920703cdb6cec38e6360d2d
Summary: Now it compiles and works.
Reviewed By: fromcelticpark
Differential Revision: D5952026
fbshipit-source-id: df0408108ab29b77592d78b29553d2e65686f2f2
Summary:
Basic implementation of the proposal in #15271
Note that this should not affect facebook internally since they are not using OSS releases.
Points to consider:
- How strict should the version match be, right now I just match exact versions.
- Wasn't able to use haste for ReactNativeVersion because I was getting duplicate module provider caused by the template file in scripts/versiontemplates. I tried adding the scripts folder to modulePathIgnorePatterns in package.json but that didn't help.
- Redscreen vs. warning, I think warning is useless because if the app crashes you won't have time to see the warning.
- Should the check and native modules be __DEV__ only?
**Test plan**
Tested that it works when version match and that it redscreens when versions don't before getting other errors on Android and iOS.
Closes https://github.com/facebook/react-native/pull/15518
Differential Revision: D5813551
Pulled By: hramos
fbshipit-source-id: 901757e25724b0f22bf39de172b56309d0dd5a95
Summary: Because `RCTUIManager` is already overcomplicated and that stuff deserves separate file and header.
Reviewed By: javache
Differential Revision: D5856653
fbshipit-source-id: 7001bb8ba611976bf3b82d6a25f5619810a35b34
Summary:
This issue has been open for a really long time, but I'm pretty sure this is the line that needed to change:
https://github.com/facebook/react-native/issues/1831
What was happening here is that `CGRectIsEmpty` returns true when either height or width is zero. With the current logic, one of those would always be zero when the parent was rendered off screen. This ensures that there the intersection be of CGSizeZero for the view to actually be clipped.
That being said, there seems to be something more complex going on here that I'm not understanding? I would think that you'd simply want to check if the child view's frame is within the bounds of the parent at all. If it was, then don't clip it. If I'm in the wrong, could someone explain this a bit more? If so, I'll fix this issue.
Using this [repository](https://github.com/jcharlet/react_native_listview_bug), this one line change fixes the issue and still clips cells as they are scrolled off screen.
Closes https://github.com/facebook/react-native/pull/15669
Differential Revision: D5815056
Pulled By: shergin
fbshipit-source-id: 32382e4954139e4d5af67d786422fd87173b1a1a
Summary: As per the comment, <Modal> uses entering/leaving the view hierarchy as a cue to show/hide the modal. By re-adding it, we are causing a bunch of confusion.
Reviewed By: shergin
Differential Revision: D5893607
fbshipit-source-id: ecd05799751a9bba843998ae93f24fe35edca8b4
Summary:
<SafeAreaView> renders nested content and automatically applies paddings reflect the portion of the view
that is not covered by navigation bars, tab bars, toolbars, and other ancestor views.
Moreover, and most importantly, Safe Area's paddings feflect physical limitation of the screen,
such as rounded corners or camera notches (aka sensor housing area on iPhone X).
Reviewed By: mmmulani
Differential Revision: D5886411
fbshipit-source-id: 7ecc7aa34de8f5527c4e59b0fb4efba3aaea28c8
Summary:
In some cases we need a way to specify some environmental data to shadow view
to improve layout (or do something similar), so `localData` serves these needs.
For example, any stateful embedded native views may benefit from this.
Have in mind that this data is not supposed to interfere with the state of
the shadow view.
Reviewed By: mmmulani
Differential Revision: D5884711
fbshipit-source-id: f0bf66e4608894ec4479b8aca262afcfba6b9f4b
Summary: Adds an onDismiss so that navigation events can be chained to the dismissing of a modal.
Reviewed By: sahrens
Differential Revision: D5852953
fbshipit-source-id: a86e36fdd5b0b206c2dd9fa248e2a88da22efa31
Summary:
This should be much more performant (and it better illustrates the intension of the code).
The fix was suggested by Adlai-Holler.
Reviewed By: mmmulani
Differential Revision: D5851595
fbshipit-source-id: 45d172a5fa796549c6dcea8f35c5cbb2a4c2d2e0
Summary:
iOS 11 now requires this to be accessed on the main thread.
I think this is causing tests to fail, as the Main Thread Checker is turned on there.
Reviewed By: javache
Differential Revision: D5826570
fbshipit-source-id: 6acb7174c756a2ad657602f14c666f71b1ee8fe9
Summary:
Remove fallback logic.
It is hard to test whether a bundle is good or bad on device, since it does the fallback, remove the fallback logic now.
Reviewed By: javache
Differential Revision: D5773542
fbshipit-source-id: 8bb4fdad4c5761ccce915f9f1c2577464e8d37d8
Summary:
fix the regression I mentioned in https://github.com/facebook/react-native/pull/15162#issuecomment-319696706
as no one is working on this, I take the step, although I know nothing about Objective C
I find the key point is that the keys in `NSDictionary` are not ordered as presented, it's a hash table, so no grantee on keys order, so I create a new array to do that, then it will check `ultralight` before `light` and `semibold` before `bold`
Closes https://github.com/facebook/react-native/pull/15825
Differential Revision: D5782142
Pulled By: shergin
fbshipit-source-id: 5346b0cb263e535c0b445e7a2912c452573248a5
Summary:
Shame on me.
Naming can be hard. We have to use positive logic to avoid this kind of bugs. :(
In the bright future we also have to rename `isYogaLeafNode` to something with positive logic, like `canHaveYogaChildNodes`.
But before we can do this, we have to have solid plan how to unify it with Android.
Reviewed By: mmmulani
Differential Revision: D5780917
fbshipit-source-id: 1ddaaea06f5618b91528cc87f1433a55b5fae4ac
Summary:
This is revert of revert of https://github.com/facebook/react-native/pull/15542
WITHOUT default RCT_MAIN_THREAD_WATCH_DOG_THRESHOLD value. So, it makes it completly opt-in feature.
When code blocks the UI thread for too long, it's a bad sign because this can prevent the app from remaining responsive. This change helps detect such responsiveness issues by warning when a React method executes on the UI thread longer than some threshold.
Reviewed By: mmmulani
Differential Revision: D5772433
fbshipit-source-id: 24fe4fc0deffe9c091a4bfc4cbd76cb4f34c4091
Summary:
Content offset was broken because on initial render contentSize is {0,0} so any positive offset is lost. Also inset top/bottom and left/right were inversed �, this led to bad initial scrolling offset when using contentInset. This fixes it by making sure contentSize is actually measured (not {0,0}. I guess it's possible that the content is ACTUALLY {0,0} but in that case I don't think it really matters).
**Test plan**
Tested that a scrollview has proper scroll position when specifying contentOffset. Also tested that it works well with contentInset.
```js
<ScrollView contentOffset={{y: 100}}>
<View style={{height: 1000}} />
</ScrollView>
```
Closes https://github.com/facebook/react-native/pull/15670
Differential Revision: D5771221
Pulled By: shergin
fbshipit-source-id: 455ed8fd5a4ad1ec61780b573d1a8ef1d77dd124
Summary:
We assign the value to an NSInteger so we should convert the NSString to an NSInteger instead of an int.
Build the app in Xcode and run it.
Closes https://github.com/facebook/react-native/pull/15806
Differential Revision: D5767118
Pulled By: shergin
fbshipit-source-id: b310511f13f5f4026d595a219d69811801d313c2
Summary:
This fixes the `testModulesAreDeallocated` test. It was sometimes failing because the bridge's module was still alive. I debugged with the Xcode memory graph and found that the bridge was actually kept alive by a pointer from the NSThread.
By killing the runloop on the thread, the thread will eventually die and thus free the bridge.
One thing I didn't investigate was whether the thread was alive because of it receiving actual messages or just because the run loop was spinning.
Reviewed By: javache
Differential Revision: D5729925
fbshipit-source-id: 304f526129d2c5e137bfd791a6f957f6169b783e
Summary: Expose webSocketDidOpen in RCTReconnectingWebSocket in order to get notified when the reconnecting websocket is opened to the endpoint.
Reviewed By: emilsjolander
Differential Revision: D5725547
fbshipit-source-id: e904c5a84d670ecf936993ec1739614f99fce09c
Summary:
When code blocks the UI thread for too long, it's a bad sign because this can prevent the app from remaining responsive. This change helps detect such responsiveness issues by warning when a React method executes on the UI thread longer than some threshold.
**Test Plan**
Changed AppState's getCurrentAppState method to sleep for 500 ms and verified that a warning was emitted:
```
2017-08-17 19:45:29.479 [warn][tid:main][RCTModuleMethod.mm:527] mainThreadWatchdog: invocation of [RCTAppState getCurrentAppState:error:] took 501ms
```
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/15542
Differential Revision: D5724764
Pulled By: shergin
fbshipit-source-id: f1dc4bf17d3657c397720a47fabc7f32bf81b7ac
Summary:
We have to have a way to track ownership of shadow view.
Previous solution with traversing the hierarchy to figure out the root view does not actually work in some cases when the view is temporary detached from hierarchy.
This is also how it work on Andorid.
Reviewed By: mmmulani
Differential Revision: D5686112
fbshipit-source-id: a23a10e8c29c7572ac69403289db136c9d5176a9
Summary:
- [x] Explain the **motivation** for making this change.
- [x] Provide a **test plan** demonstrating that the code is solid.
- [x] Match the **code formatting** of the rest of the codebase.
- [x] Target the `master` branch, NOT a "stable" branch.
There is a problem where setting a bigger fontSize in PickerItem style
clips the top and bottom of the text.
This solves that problem by computing the row height using the font
size.
Create a PickerIOS component and set a larger font size (e.g. 50). The row height will grow accordingly.
Example with `fontSize=50`: [Screenshot](http://i.imgur.com/YwK5fOc.png)
Closes https://github.com/facebook/react-native/pull/13513
Differential Revision: D5692124
Pulled By: shergin
fbshipit-source-id: 4629403e37ad68cdbc0b17b48ba924a77e133078
Summary:
> The property contentInset can change the maximum and minimum values of the content offset to allow scrolling outside of the scrollable area. Its type is UIEdgeInsets, which consists of 4 numbers: {top, left, bottom, right}. When you introduce an inset, you change the range of the content offset. For example, setting the content inset to have a value of 10 for its top value allows the content offset’s y value to reach -10. This introduces padding around the scrollable area.
( https://www.objc.io/issues/3-views/scroll-view/ )
See also: https://github.com/facebook/react-native/pull/15395
Reviewed By: mmmulani
Differential Revision: D5607192
fbshipit-source-id: 1acd6a84e2bcfefc6e82861cfbdfe6247d0e4264
Summary:
On an iPhone running iOS 10.3.3, I'm not seeing the UIContentSizeCategoryDidChangeNotification fire when changing the system's font scale setting. Registering for the event on `nil` instead of on the application object fixes the issue.
**Test Plan**
Verified that text in an RN app changes size when you change the system's font scale setting (Settings -> General -> Accessibility -> Larger Text). By default, RN text is supposed to scale with the system setting.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/15522
Differential Revision: D5657449
Pulled By: shergin
fbshipit-source-id: d7a6a730c5cd6eb3833274a1f2029663ad3a7ad2
Summary:
**Motivation**
On Apple TV, pressing the menu button destroys the native view that backs the `Modal` component, causing an app using this component to get into a broken state. This fix implements `onRequestClose` for tvOS to have the same behavior as it does for the Android back button.
**Test plan**
Manually tested this with the `ModalExample` in the `RNTester` app. See also the test code in issue #15313.
Closes https://github.com/facebook/react-native/pull/15341
Differential Revision: D5651035
Pulled By: shergin
fbshipit-source-id: 54bf66887bbe85940567e63e90b437ac4a8daf9a
Summary:
(This diff was decoupled from D4983054 which landing was quite delayed.)
`RCTUnsafeExecuteOnMainQueueOnceSync()` synchronously executes a block once, on main queue.
I found that our old implementation of `RCTScreenScale()` causes deadlock when it is called from main and background thread simultaneously.
After I implemented my own solution I googled this issue and found an article by Ben Alpert with this awesome helper:
https://benalpert.com/2014/04/02/dispatch-once-initialization-on-the-main-thread.html
So, I found it super useful and borrowed it.
Hey spicyj! :)
Reviewed By: fkgozali
Differential Revision: D5632592
fbshipit-source-id: dff43a5780b7404a3cc109c66c131cef4f4df429
Summary:
This shows progress for the download of the JS bundle (different from the packager transform progress that we show already). This is useful especially when loading the JS bundle from a remote source or when developing on device (on simulator + localhost it pretty much just downloads instantly). This will be nice for the expo client since all bundles are loaded over the network and can take several seconds to load.
This depends on https://github.com/facebook/metro-bundler/pull/28 to work but won't crash or anything without it, it just won't show the progress percentage.
**Test plan**
Tested that bundle download progress is shown properly in RNTester on both localhost + simulator and on real device with network conditionner to simulate a slow loading bundle.
Tested that it doesn't cause issues if the packager doesn't send the Content-Length header.
Closes https://github.com/facebook/react-native/pull/15066
Differential Revision: D5449073
Pulled By: shergin
fbshipit-source-id: 43a8fb559393bbdc04f77916500e21898695bac5
Summary:
**Motivation**
Fix flickering in TabBarIOS on Apple TV... issue #15081
After this change, on Apple TV, TabBarIOS item selections will be controlled purely from the native side after initial render with the `selected` prop. This is necessary because the `UITabBar` implementation in tvOS moves the selection before calling `shouldSelectViewController:`; this issue does not occur on iOS.
**Test plan**
Existing CI should still pass. Issue is resolved when testing the example code in #15081 .
Closes https://github.com/facebook/react-native/pull/15220
Differential Revision: D5601671
Pulled By: javache
fbshipit-source-id: c18e7d3482d6c07d534ff40a443a6f642d4267bb
Summary:
It is not itemPositoning it is itemPositioning
I have test it on iOS and tvOS
Closes https://github.com/facebook/react-native/pull/15426
Differential Revision: D5591807
Pulled By: javache
fbshipit-source-id: 0ad0bc32012c63f93f6b1528cae46c6dcba56706
Summary:
Here, `reactTag` is an `NSNumber *` which uses `%@` as the format specifier. Newer versions of clang can warn or error on this. This change prevents that from happening.
See also #15402
Local builds with clang 5.
Closes https://github.com/facebook/react-native/pull/15414
Differential Revision: D5583703
Pulled By: javache
fbshipit-source-id: a6d0d2246725cd096b1f3cd062ab5924740ab76c
Summary:
[`CxxModule::Method::callbacks`](2161f92aaf/ReactCommon/cxxreact/CxxModule.h (L66)) is `size_t` which uses `%zu` as the format specifier. Newer versions of clang can warn or error on this. This change prevents that from happening.
Local builds with clang 5.
Closes https://github.com/facebook/react-native/pull/15402
Differential Revision: D5583710
Pulled By: javache
fbshipit-source-id: 1d1e740c275fddfea177cf9476cd1d03b7e27330
Summary: Expose didCloseWithCode in RCTReconnectingWebSocket in order to get notified when the reconnecting websocket is closed by the end-point.
Reviewed By: javache
Differential Revision: D5573394
fbshipit-source-id: 78bffeb98c6bf32b059194fc07ffc1f0a7bf4aae
Summary:
We've simplified a lot of the conditions for eager of the module init so now we can introduce a final switch to allow modules to opt-out (and in the future opt-in if they still require the behaviour).
We now require you to be explicit about the intended behaviour and implement the `+ (BOOL)requiresMainQueueSetup` method on your module. When you return YES from this method, it tells the bridge the module needs to be created on the main thread (and to avoid deadlocks, we do so eagerly during bridge startup). When you return NO, the native module will be initialised when it's first accessed from JS.
The current behaviour is maintained but a warning is emitted until the new API is adopted.
Reviewed By: fkgozali
Differential Revision: D5527788
fbshipit-source-id: 56d38f81e58cf950547b9780e89bfac4667eeaaa
Summary:
When false, ScrollView disables use of pinch gestures to zoom in and out. This allows ScrollView's pinch gesture responder to be disabled to only allow zooming programmatically. The default value is ~false~ true.
**Test Plan**
Tested that pinch gesture responder is disabled when pinchEnabled=false.
/cc nicklockwood sahrens
🍺
Closes https://github.com/facebook/react-native/pull/10037
Differential Revision: D5491953
Pulled By: shergin
fbshipit-source-id: eae16f92ec616e415b4ddacfccb84c697582daf9
Summary:
Fixes an issue with installing third party on iOS when the project's path contains a space, no matter where the space is in the path.
__Error__
```
/Users/AwesomeUser/Library/Developer/Xcode/DerivedData/AwesomeProject-xxx/Build/Intermediates.noindex/React.build/Debug-iphoneos/double-conversion.build/Script-190EE32F1E6A43DE00A8543A.sh: line 3: /Users/AwesomeUser/path contain space/scripts/ios-install-third-party.sh: No such file or directory
/Users/AwesomeUser/Library/Developer/Xcode/DerivedData/AwesomeProject-xxx/Build/Intermediates.noindex/React.build/Debug-iphoneos/double-conversion.build/Script-190EE32F1E6A43DE00A8543A.sh: line 3: exec: /Users/AwesomeUser/path contain space/scripts/ios-install-third-party.sh: cannot execute: No such file or directory
```
Closes https://github.com/facebook/react-native/pull/15377
Differential Revision: D5572671
Pulled By: shergin
fbshipit-source-id: 102727fc1b820e399e170c9c0cb73fd5d1e018d5
Summary:
Hey!
So, I was interested to contibure, and started from todo
Thank
Closes https://github.com/facebook/react-native/pull/14823
Differential Revision: D5546610
Pulled By: javache
fbshipit-source-id: 58e1b67786cbafa20399ac12dde9fcc3920abe94
Summary:
This will save us precious microseconds and it's prettier to look at.
Closes https://github.com/facebook/react-native/pull/15276
Differential Revision: D5531823
Pulled By: javache
fbshipit-source-id: f8a97ec2a03e3cfdf1801457a481ec62a9371eeb
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Reviewed By: javache
Differential Revision: D5517552
Pulled By: hramos
fbshipit-source-id: c9ce4bf331b3d243228268d826fdd4dcee99981d
Summary:
Hi React Native folks! Love your work!
To make contributing easier, this sets the indentation settings of all the Xcode projects to 2 spaces to match their contents.
Closes https://github.com/facebook/react-native/pull/15275
Differential Revision: D5526462
Pulled By: javache
fbshipit-source-id: cbf0a8a87a1dbe31fceed2f0fffc53839cc06e59
Summary:
**Motivation**
Properly support long presses on the Apple TV remote, and also enable dev menu functionality on a real Apple TV device (shaking an Apple TV doesn't work 😄 )
**Test plan**
New example added to `RNTester`.
Closes https://github.com/facebook/react-native/pull/15221
Differential Revision: D5526463
Pulled By: javache
fbshipit-source-id: a61051e86bc82a9561eefc1704bed6b1f2617e05
Summary:
The next in my series of :atom: migrations.
Closes https://github.com/facebook/react-native/pull/15277
Differential Revision: D5526460
Pulled By: javache
fbshipit-source-id: e4ba54a5911c4a76280edf8aa164ac5aa935a945
Summary:
Adds a queue to postMessage so that messages sent close together are not lost.
Setting location="a";location="b" results in only "b" reaching shouldStartLoadWithRequest. Making the second update asynchronous with setTimeout does not fix the issue unless a delay is added.
With this update, postMessage queues "b" until it gets a "message:received" event that confirms "a" has already been processed.
The included test sends two messages from a webview and checks that both are received. It fails against the preexisting code with the first message being dropped.
Closes https://github.com/facebook/react-native/pull/11304
Differential Revision: D5481385
Pulled By: hramos
fbshipit-source-id: 9b6af195eeff8f20c820e2fcdac997c90763e840
Summary: When loading bundle from packager, "application/javascript" and "text/javascript" both refer to JS, so let's allow both for now.
Reviewed By: javache
Differential Revision: D5499446
fbshipit-source-id: f0b42e2fe5dc043a68d2c8df6a9f81e6dd995b57
Summary:
**Motivation:** This error can be a symptom of various other issues (see: an issue search for `__fbBatchedBridge is undefined`). I'm hoping to provide slightly more information about what might be going wrong and how to self-help.
**Test Plan:** Run some JS before the bridge has injected itself into the JS context. (sort of copping out here since the change is just to an error string literal.)
Closes https://github.com/facebook/react-native/pull/15184
Differential Revision: D5499445
Pulled By: javache
fbshipit-source-id: 8051869feb5fe5fc630516972775c134f6e41a04
Summary:
This is the first PR from a series of PRs grabbou and me will make to add blob support to React Native. The next PR will include blob support for XMLHttpRequest.
I'd like to get this merged with minimal changes to preserve the attribution. My next PR can contain bigger changes.
Blobs are used to transfer binary data between server and client. Currently React Native lacks a way to deal with binary data. The only thing that comes close is uploading files through a URI.
Current workarounds to transfer binary data includes encoding and decoding them to base64 and and transferring them as string, which is not ideal, since it increases the payload size and the whole payload needs to be sent via the bridge every time changes are made.
The PR adds a way to deal with blobs via a new native module. The blob is constructed on the native side and the data never needs to pass through the bridge. Currently the only way to create a blob is to receive a blob from the server via websocket.
The PR is largely a direct port of https://github.com/silklabs/silk/tree/master/react-native-blobs by philikon into RN (with changes to integrate with RN), and attributed as such.
> **Note:** This is a breaking change for all people running iOS without CocoaPods. You will have to manually add `RCTBlob.xcodeproj` to your `Libraries` and then, add it to Build Phases. Just follow the process of manual linking. We'll also need to document this process in the release notes.
Related discussion - https://github.com/facebook/react-native/issues/11103
- `Image` can't show image when `URL.createObjectURL` is used with large images on Android
The websocket integration can be tested via a simple server,
```js
const fs = require('fs');
const http = require('http');
const WebSocketServer = require('ws').Server;
const wss = new WebSocketServer({
server: http.createServer().listen(7232),
});
wss.on('connection', (ws) => {
ws.on('message', (d) => {
console.log(d);
});
ws.send(fs.readFileSync('./some-file'));
});
```
Then on the client,
```js
var ws = new WebSocket('ws://localhost:7232');
ws.binaryType = 'blob';
ws.onerror = (error) => {
console.error(error);
};
ws.onmessage = (e) => {
console.log(e.data);
ws.send(e.data);
};
```
cc brentvatne ide
Closes https://github.com/facebook/react-native/pull/11417
Reviewed By: sahrens
Differential Revision: D5188484
Pulled By: javache
fbshipit-source-id: 6afcbc4d19aa7a27b0dc9d52701ba400e7d7e98f
Summary:
In iOS11, Apple added a new layout feature called "Safe Areas" (this blog post talks a bit about it: https://www.bignerdranch.com/blog/wwdc-2017-large-titles-and-safe-area-layout-guides/).
UIScrollView is one component that is affected by this change in Apple's API. When the `contentInsetAdjustmentBehavior` is set to `automatic`, for example, it will adjust the insets (and override any manually set insets) automatically based on whether or not there's a UINavigationBar, a UITabBar, a visible status bar, etc on the screen. Frustratingly, Apple decided to default to `Automatic` for this behavior, which will cause any apps that set contentInset/contentContainerStyle padding to have their values offset by, at the very least, the size of the status bar, when they compile their app for iOS 11. Here's more information about this behavior: https://developer.apple.com/documentation/uikit/uiscrollview/2902261-contentinsetadjustmentbehavior?language=objc
Mostly, this is a really straightforward change -- it simply adds a new iOS-only prop to ScrollView that allows setting `contentInsetAdjustmentBehavior`. But I did decide to default the behavior to `never`, so that it mimics the behavior we've seen in iOS < 11. I think it's good to keep something as crucial as scrollview content insets non-magical, and also keep it behaving similarly between platforms.
Closes https://github.com/facebook/react-native/pull/15023
Differential Revision: D5441491
Pulled By: shergin
fbshipit-source-id: 7b56ea290f7f6eca5f1d996ff8488f40b866c2e6
Summary:
**Issue:**
Some fonts are defined with weights that don't match with the UIFontWeight constants.
**Example:**
UIFontWeightTraits for Roboto font
Light: -0.230
Thin: -0.365
Currently, the UIFontWeightTrait is always used if it != 0.0, and given the UIFontWeight constants for Light and Thin:
UIFontWeightThin -0.6
UIFontWeightLight -0.4
A style font weight of "300" or "200" will both resolve to Roboto-Thin as its weight -0.365 is closer to -0.4 (UIFontWeightLight) and -0.6 (UIFontWeightThin) than -0.230 (Roboto-Light).
**Proposed fix:**
When resolving `getWeightOfFont` try to match the name of weight to the name of the font first, and guess the font with UIFontWeightTrait as the fall back.
**Test Plan:**
Attempt to display Roboto at weights "200" and "300" and Roboto-Thin and Roboto-Light should be displayed correctly.
Current:
Fixed:
Closes https://github.com/facebook/react-native/pull/15162
Differential Revision: D5479817
Pulled By: javache
fbshipit-source-id: a9f93d8ce69a96fb685cb09393d1db42486cc0c2
Summary:
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15156
Differential Revision: D5479265
Pulled By: shergin
fbshipit-source-id: a2dfa3a4357e126838a17dac4797d1d845cd56ae
Summary:
When using the packager behind something like an http tunnel it is possible something else than JS is returned, in that case throw an error instead of trying to parse it.
This is useful for Expo since the packager runs behind ngrok. This allows to intercept that error and show a more meaningful error message based on the ngrok response.
**Test plan**
Tested by changing the packager to return text/html content type and validate that the error shows up properly.
Also tested that it works when multipart response is disabled.
<img width="354" alt="screen shot 2017-07-19 at 8 01 58 pm" src="https://user-images.githubusercontent.com/2677334/28394905-39e86d52-6cbe-11e7-9059-13a85816a57e.png">
Closes https://github.com/facebook/react-native/pull/15112
Differential Revision: D5459395
Pulled By: shergin
fbshipit-source-id: aaea7ab2e1311ee8dc10feb579adf9b9701d8d4c
Summary:
* Now `setFrame:` is called by autoresizing masks, so it is safe.
* Nobody calls `setBounds:`, so it is also safe.
Reviewed By: javache
Differential Revision: D5414441
fbshipit-source-id: 6fc51c7598c4817301db51f627aa1e9840642fec
Summary:
Previous `contentOffset` can be invalid for a new layout and overscroll the ScrollView, so the diff fixes that.
Also documented here: https://github.com/facebook/react-native/issues/13566
Reviewed By: mmmulani
Differential Revision: D5414442
fbshipit-source-id: 7de1b4a4571108a37d1795e80f165bca5aba5fef
Summary:
Surprisingly enough, even if semantically the code remains identical, layouting via autoresizing masks applies changes to subviews a bit earlier than iOS calls `layoutSubviews`.
This allows us to avoid situations where we already explicitly set calculated by Yoga frames and want to scroll to some subview, but actual layout have not done yet and internal views has wrong frames.
Reviewed By: javache
Differential Revision: D5414440
fbshipit-source-id: d4152c9c68dc17f6827832dcb45e5ba86fb82831
Summary:
5701ae2145 didn't add the new files to xcodeproj, the project is still building fine but is getting rejected by apple app analysis tools because it thinks we are trying to use a private api `rootView`. Just adding the files that define the selector makes it get accepted now.
**Test plan**
Tested that I'm now able to submit a build on testflight using this change.
Closes https://github.com/facebook/react-native/pull/15072
Differential Revision: D5444838
Pulled By: hramos
fbshipit-source-id: a290ebd23c2510e103934a550d1b37899ce9c093
Summary:
This PR fixes#15006 by removing all UI API calls from RCTScrollEvent.
`-[RCTScrollEvent arguments]` can now be called from a background thread.
The Main Thread Checker of Xcode 9 will not any longer produce runtime issues when calling this method.
1. create a React Native (version: this PR) project with a scroll view
2. open it in Xcode 9
3. launch it
4. scroll the scroll view
5. observe the runtime issues in Xcode. There should not contain "UI API called from background thread"-issues.
I verified my changes on this branch: https://github.com/HeEAaD/Demo-ReactNative-UI-not-on-main-thread/tree/fix
<!--
Thank you for sending the PR!
If you changed any code, please provide us with clear instructions on how you verified your changes work. In other words, a test plan is *required*. Bonus points for screenshots and videos!
Please read the Contribution Guidelines at https://github.com/facebook/react-native/blob/master/CONTRIBUTING.md to learn more about contributing to React Native.
Happy contributing!
-->
Closes https://github.com/facebook/react-native/pull/15008
Differential Revision: D5424734
Pulled By: shergin
fbshipit-source-id: 56beec2d7603ea6782d55622567509f3758a4517
Summary:
It's very important in complex UIs to be able to apply alpha channel-based masks to arbitrary content. Common use cases include adding gradient masks at the top or bottom of scroll views, creating masked text effects, feathering images, and generally just masking views while still allowing transparency of those views.
The original motivation for creating this component stemmed from work on `react-navigation`. As I tried to mimic behavior in the native iOS header, I needed to be able to achieve the effect pictured here (this is a screenshot from a native iOS application):
In this image, there are two masks:
- A mask on the back button chevron
- A gradient mask on the right button
In addition, the underlying view in the navigation bar is intended to be a UIBlurView. Thus, alpha masking is the only way to achieve this effect.
Behind the scenes, the `maskView` property on `UIView` is used. This is a shortcut to setting the mask on the CALayer directly.
This gives us the ability to mask any view with any other view. While building this component (and testing in the context of an Expo app), I was able to use a `GLView` (a view that renders an OpenGL context) to mask a `Video` component!
I chose to implement this only on iOS right now, as the Android implementation is a) significantly more complicated and b) will most likely not be as performant (especially when trying to mask more complex views).
Review the `<MaskedViewIOS>` section in the RNTester app, observe that views are masked appropriately.
Closes https://github.com/facebook/react-native/pull/14898
Differential Revision: D5398721
Pulled By: javache
fbshipit-source-id: 343af874e2d664541aca1fefe922cf7d82aea701
Summary:
Just a little typo fixing and wording clean up around some header docs.
Closes https://github.com/facebook/react-native/pull/14947
Differential Revision: D5398609
Pulled By: javache
fbshipit-source-id: 3eb40ef3308130c1d28b2efc7bb64d493e98825b
Summary:
**Motivation**
This is a re-worked version of #14260, by shergin's suggestion.
For iOS, if you want to inherit from a native ViewManagers, your custom ViewManager will not automatically export the parents' props. So the only way to do this today, is to basically copy/paste the parent ViewManager-file, and add your own custom logic.
With this PR, this is made more extensible by exporting the `baseModuleName` (i.e. the iOS `superclass` of the ViewManager), and then using that value to re-establish the inheritance relationship in `requireNativeComponent`.
**Test plan**
I've run this with a test project, and it works fine there. But needs more testing.
Opened this PR as [per shergin's suggestion](https://github.com/facebook/react-native/pull/10946#issuecomment-311860545) though, so we can discuss approach.
**Discussion**
* Android already supports inheritance, so this change should be compatible with that. But, not every prop available on `UIManager.RCTView.NativeProps` is actually exported by every ViewManager. So should `UIManager.RCTView.NativeProps` still be merged with `viewConfig.NativeProps`, even if the individual ViewManager does not export/use them to begin with?
* Does this break other platforms? [UWP](https://github.com/Microsoft/react-native-windows)?
Closes https://github.com/facebook/react-native/pull/14775
Differential Revision: D5392953
Pulled By: shergin
fbshipit-source-id: 5212da616acfba50cc285e2997d183cf8b2cd09f
Summary:
Fixed the test script to properly setup our third-party deps and tweaked the third-party specs a bit so they work correctly.
This currently works for projects using static libraries, but fails when using dynamic libraries (`--use-libraries`)
cc mhorowitz alloy
Closes https://github.com/facebook/react-native/pull/14100
Differential Revision: D5380728
Pulled By: javache
fbshipit-source-id: e78b6bd4466ebf2bf30b7e361eff10ec14b36a55
Summary:
This diff fixes a possibly inconsistent state of view hierarchy caused by async delayed deleting manipulation on UIView's tree.
Even if new approach may seem tricky, the previous one was just terribly wrong.
Reviewed By: javache
Differential Revision: D5374670
fbshipit-source-id: 36f27330aa8b0e4e00fe43739afe3bc6a8602e30
Valentin Shergin
Simon Racz
Jason Carreiro
Ramanpreet Nara
Alex Dvornikov
Janic Duplessis
tfallon@mail.depaul.edu
Mehdi Mulani
Jakub Grzmiel
Jia Li
Justin Reynolds
Michał Gregorczyk
Paco Estevez Garcia
Brian Vaughn
Kellie Medlin
Chris Zheng
Pieter De Baets
Sean Holbert
Ben Nham
Neo
Marc Horowitz
James Ide
Gabriel Bull
Gilad Novik
Mark Smith
Jing Chen
Sebastian Lund
Nurzhan Bakibayev
Adam Comella
Jacob Parker
Alin Panaitiu
Adam Comella
Douglas Lowder
Rafael Oleza
Janic Duplessis
Dmitry Zakharov
Pieter De Baets
Julien K
Dave Lee
Jake Murzy
Dmitry Patsura
Adlai Holler
Adam Miskiewicz
Douglas Lowder
Theo Yaung
Tom Clarkson
Andrew Krieger
Saad Ismail
Kevin Gozali
Pieter De Baets
Ben Roth
Philipp von Weitershausen
Kip Ricker
Tomas Reimers
Spencer Ahrens
Steffen Matthischke
Yu Wang
Eli Perkins
Christian Brevik
