Summary:
Special thanks for Joshua Gross for flagging this problem!
This diff implements a custom evicting hash map designed specially to hold text measurement information. The key feature of this is custom equality checks and hashing functions.
They are designed around the following principals:
* Decorative text attributes (such as color, shadows, etc) has no effect on layout, therefore they should not be taking into account;
* `minimum height`, `minimum width`, and `maximum height` don't affect the measurement;
* the value of `layout metrics` are important only for `attachment` fragments.
After I redo all tests, I will enable this for Android-specific TextLayoutManager in separate diff.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18848583
fbshipit-source-id: 46c2fc445fbd1823afc5e7498e37de75381258b1
Summary:
In the previous diff, we noted that the maximum height is not really important for text measurement. That diff make is in code.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18848585
fbshipit-source-id: 5fe0ea8f76487a50baa8a2e024663a85afcd9861
Summary:
Here the deal with the clamp thing:
A layout engine asks nodes to measure their content providing layout constraints (min and max size) and that would be kind from nodes to return a result that in space of those constraints. Sometimes, satisfying that is an additional separate step of that operation, e.g. if we know that the intrinsic size of some node is `{100, 100}`, we need to clamp that to satisfy constraint `[min: {200, 200}, max: {inf, inf}]`.
In case when we need to cache measure information, it becomes tricky enough when we need to make the cache work most efficiently. For the case of measuring Text, we have an insight: the available maximum width is important, the rest three metrics (maximum height and minimum size) are not.
That means that any changes in those three metrics don't affect the actual measurement result but will affect the final value because the actual value will be clamped by constraints that didn't influence measuring in the first place.
That's why moving clamping outside of a cache is the first step into making it more efficient.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18848584
fbshipit-source-id: 8feeb3f1a9d0e9691abac8be43639487a626fec3
Summary:
Before this change, C++ couldn't propagate changes that updated TextInputs that were completely empty. In C++ the AttributedString cannot contain Fragments with empty text, so a completely empty TextInput would have no Fragments; this breaks the C++ state value updating infra since it relies on copying over existing fragments.
Instead, now we propagate default TextAttributes and ShadowView through State, so that State updates can use them to construct new Fragments.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D18835048
fbshipit-source-id: 58ac94c5454c8610c6287b096b62199045e5879b
Summary:
Support for modifying AndroidTextInputs with multiple Fragments was added on the Java side in a previous diff.
This diff adds support on the C++ side for the following scenario:
A <TextInput> is initially given contents via children <Text> notes, which represents multiple Fragments (that could have different TextAttributes like color, font size, backgroundcolor, etc). The Android EditText view must get this initial data, and then all updates after that on the Android side must flow to C++ so that the C++ ShadowNode can perform layout and measurement with up-to-date data.
At the same time, the <TextInput> node could be updated from the JS side. All else equal, this would cause the native Android EditText to be replaced with the old, original contents of the <TextInput> that may not have been updated at all from the JS side.
To mitigate this, we keep track of two AttributedStrings with Fragments on the C++ side: the AttributedString representing the values coming from <TextInput> children, from JS (`treeAttributedString`); and the AttributedString representing the current value the user is interacting with (`attributedString`). If the children from JS don't change, we don't update Android/Java with that AttributedString. If the children from JS do change, we overwrite any user input with the tree from JS.
Changelog: [Internal]
Reviewed By: shergin, mdvacca
Differential Revision: D18785976
fbshipit-source-id: a1f3a935e02379cabca8ab62a39cb3c0cf3fbca5
Summary:
For future diffs, we need to check AttributedStrings for equality.
It turns out that any time props or state change, two `parentShadowView`s will never be equal to each other, even if we'd consider them equal for our use-cases here for AttributedStrings. Just compare the tags instead of the whole object.
NOTE: I don't have any strong opinions about how we should be comparing them. It just isn't working currently for AndroidTextInput. Comparing tags seems convenient and reasonably correct for now.
Changelog: [Internal]
Reviewed By: shergin
Differential Revision: D18786004
fbshipit-source-id: 13c0e881cd8d2c2a207e8891309b3c9b880b827f
Summary:
Currently the TextInput background is same as the background of the `text` value's attributes, because of the way we're parsing props and using the TextInput's props both for the background of the TextInput, and for the AttributedString/background color of the `text` prop node's attributes. If the background color has opacity, the `text` prop node will not have the correct background because it will be applied twice. Fix it.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18760384
fbshipit-source-id: 0cdcc8dd8839dd47e8fe0f593b4696bc16a62333
Summary:
Fix and simplify `AndroidTextInputShadowNode::getAttributedString` so that it (1) works, and (2) is aligned with the equivalents in the old Java code.
The issue is that we weren't picking up `text` attributes since we're only traversing children and not the TextInput node itself. If a `text` attribute is present it needs to be treated as its own Text node.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18739830
fbshipit-source-id: 4b3bc81dbe8c241c2e06fe5be1f9b50e49132890
Summary:
This is necessary for allowing TextInput updates from Java.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18739831
fbshipit-source-id: 0ba2d7eac96cac7471c5e46cc1e03a4d065229f5
Summary:
Sometimes, very irregularly, measuring an empty string crashes/freezes iOS internal text infrastructure. This is our last line of defense.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC, mdvacca
Differential Revision: D18802308
fbshipit-source-id: addf523b31b78b0777be7eeaeee140ac8416393b
Summary:
Now RCTTextLayoutManager (and TextLayoutManager) not only accept `AttributedStringBox` but also is capable to measure such kind of string when it contains a pointer to NSAttributedString.
The same can be implemented for Android when/if needed.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18670791
fbshipit-source-id: f19089de64d00e1290767310a500ade4cede4685
Summary:
The diff implements a new class called `AttributedStringBox` that represents an object storing a shared `AttributedString` *or* a shared pointer to some opaque platform-specific object that can be used as an attributed string. The class serves two main purposes:
- Represent type-erased attributed string entity (which can be platform-specific or platform-independent);
- Represent a container that can be copied with constant complexity.
Why? Several reasons:
- Sometimes it makes sense to keep an attributed string as a shared resource. This way we don't need to pay for expensive copying and we also implement a copy-on-write semantics on top of that if needed.
- We need to extend a TextLayoutMeasure API to support measuring some platform-specific attributed string implementation to remove the necessity of converting a string back and forth between representations. That's especially important for TextInput because we will need to measure that very efficiently (and the source of measuring, in this case, is a platform attributed string).
In other words, we need something to store inside TextInputState to measure and update very efficiently. The source of this data might be a native TextInput control or a data from React, to represent that kinda object we need this data structure (and interfaces that deal with it).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18670793
fbshipit-source-id: bc0164f801f28642f7c6da340af12acf33b85d24
Summary:
We need this type to work with string ranges (e.g. working with selection ranges). This diff implements parsing and printing that as well.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18607656
fbshipit-source-id: f2cfd7c5b7ba9f225a9a0c5a078947a220b2f30d
Summary:
Our current lazy compilation parent scope issue caused us to only have a
single lexical scope, which was taken to be the global scope. This
effectively hid all local variables. Additionally, the variables were
not marked as enumerable, so Chrome didn't show them.
As further improvements, 'this' is now included, and we more correctly
tag parent scopes as closures.
Changelog: [Internal]
Reviewed By: avp
Differential Revision: D18671527
fbshipit-source-id: cbbf9fbd319e433b9f681bd23e4ad7b4bb4a3d74
Summary:
In AndroidTextInput, support codegen'd ViewCommands in native and add three commands that will eventually replace usage of setNativeProps on Android.
TextInput will use these commands in a future diff.
Changelog: [Internal]
Reviewed By: TheSavior
Differential Revision: D18612150
fbshipit-source-id: 5d427040686e8c5ab504dd845bc8ef863f558c35
Summary:
In C++ we return default/placeholder text instead of text in `getAttributedString` so that measurement is correct. This is fine but we shouldn't actually set the attributedString on the ReactEditText view.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18672369
fbshipit-source-id: 1bb5cddda3cf78f2cff6f805e67c8994ab32ee7c
Summary:
iOS and other platforms have direct access to C++ StateT structs, whereas Java only has access to a Java map equivalent - state updates from Java can't update complex types, or must incur significant cost to reconstruct large objects from their folly::dynamic representation (not to mention the complexity of implementing the Java-to-C++ struct converters). Thus it's hard for Java to update StateT's with complex types on the C++ side.
This diff makes a minor change to Android's updateState which uses both the folly::dynamic data from Java as well as the previous State, so each StateT can have fields that are read-only from the Java perspective.
Motivation: For AndroidTextInput we need to set params from Java, without being able to send all of the State params from Java.
In this diff, we introduce a new State constructor that takes the previous State value and a folly::dynamic. It is up to each State implementation how the additional parameter will be used.
We migrate every existing component except for AndroidTextInput in this diff.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18672365
fbshipit-source-id: 4469e0a3c7658c204089c6fed39394979883f124
Summary:
Use a similar setup as Paragraph, and support in Fabric:
- Correct measuring of AndroidTextInput
- Correct display of AndroidTextInput attributed strings
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18669957
fbshipit-source-id: 84e0ad8021c9edf8219e0c673c781276ca29787d
Summary:
See previous diff implementing failing unit test in RawPropsTest.cpp.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18664014
fbshipit-source-id: ef827bce8c676666b2ce4d5db4abbb0ab11cc454
Summary:
See previous diff where I added RawPropsTest.cpp to unit-test this functionality. Before this, if you looked up a prop name that does not exist, the prop parser would enter an infinite loop.
I also took this opportunity to comment the block a little bit as it's not super intuitive at first glance.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18662135
fbshipit-source-id: 319a3b80d1c606db18b2added9f2aa99d4d03407
Summary:
Add RawPropsTests unit tests.
The general idea is to cover the normal props use-cases and then add a few abnormal cases and some errors, to make sure nothing crashes.
The final test uncovers an infinite loop in RawProp parsing.
Changelog: [Internal]
Reviewed By: fkgozali
Differential Revision: D18662136
fbshipit-source-id: 2f603b4c3e32f2d4334587e898ea81ad025b07b6
Summary:
... because the original name made no sense.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18607834
fbshipit-source-id: bf32d2b61d1c3deccba0b599b303ede0b82e6dd6
Summary:
This diff makes the parsing *Props object with sub-props with duplicating names deterministic: only the first one will be assigned. Before this change, the order was not guaranteed because `qsort` sorting algorithm is not stable and because binary search that we use to search in the sorted array does not handle duplicates deterministically.
The behavior when the only sub-prop (the first one) is being assigned actually desirable feature that exists on purpose. There are places where it's desired behavior (like TextInputProps) and in cases where it's not desired (we don't really have those), it's easy to "fix" implementing the custom constructor.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18607657
fbshipit-source-id: aa53a320e6a48877a0dd1b9351dfcc8a9f419b38
Summary:
Before this change `AttributedString::Fragment` had two ShadowView objects (`shadowView` and `parentShadowView`). This diff unifies those two things into one. That allows us to save some CPU and memory and makes things a bit simpler. Besides that, now the length of NSAttributedString and AttributedString is now always the same (it's one Unicode character for an attachment for both).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18607658
fbshipit-source-id: 502ae244e98a52694adc0d646650f8ea0d7922ae
Summary:
We need to call all custom base constructors as part of a custom constuctor of the superclass otherwise C++ will use the default one (and that's not what we want here).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18607654
fbshipit-source-id: 6e6154ce4b546c0717a8a67e3c497dfcd696ec41
Summary:
Two changes:
* Now we pass the given `priority` to the next function;
* The default value for `updateState` is now the same as a default value in another overload of the same function (AsynchronousBatched).
All that don't change anything for now because sync event dispatching is disabled (that will matter bit later thought).
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: JoshuaGross
Differential Revision: D18607655
fbshipit-source-id: 9dc7cdac9f347e09449a931c780e613925882a1e
Summary:
Currently, if you try to inspect globals in the debugger and they have
properties that throw exceptions, the app redscreens. In particular,
inspecting any function triggers the bug because of `arguments` and
`caller`.
This diff catches the exception and shows a placeholder instead.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D18664765
fbshipit-source-id: 0c662f3d97b21a29c57a1dd724e63d17a3b4e263
Summary:
Adds BitUtils to be used later instead of Bitfield.h
##Changelog:
[Internal][Yoga] : Adds BitUtils to be used later instead of Bitfield.h
Reviewed By: astreet
Differential Revision: D18519609
fbshipit-source-id: 8353929543505a7d80d66281adb801d34372beed
Summary:
We hope that will help us to understand more.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18599164
fbshipit-source-id: 431f83de707fc7113e04abd3dd5b59ee5c9cc675
Summary:
We are rolling out exact-by-default syntax to xplat/js.
I had to manually move around some comments to preserve proper placement.
Changelog: [Internal]
Reviewed By: jbrown215
Differential Revision: D18633611
fbshipit-source-id: 48f7468dcc55b1d00985419d035a61c6820b3abe
Summary:
In AndroidTextInput ShadowNode, return AttributedString for placeholder text if text is empty. This ensures that empty TextInputs will have non-zero height.
Changelog: [Internal]
Reviewed By: mdvacca
Differential Revision: D18623063
fbshipit-source-id: 2eec2b794b526e8ff5435352e20ccb659358fc84
Summary:
FATAL crashes the app, which was never the intent of that log message.
We need to use ERROR instead.
Changelog: [INTERNAL]
Reviewed By: fkgozali, zackargyle, mdvacca
Differential Revision: D18597249
fbshipit-source-id: 523c96550f97e837e1957c933786acf28033e60a
Summary:
The constructor arguments to `ConcreteSystraceSection` are actually used. It seems like they were accidentally marked unused in D14181748.
Changelog:
[iOS][Fixed] - Remove __unused annotation from ConcreteSystraceSection ctor args.
Reviewed By: PeteTheHeat
Differential Revision: D18574190
fbshipit-source-id: 38d58da794341d4ecc52f3bc16e05ef2757cca1d
Summary:
Changelog: [Internal]
In paper implementation:
`accessibilityActivate` returns NO in case `onAccessibilityTap` is nil.
In Fabric we have no option to detect whether `onAccessibilityTap` is nil or isn't but we don't want to prevent VoiceOver from tapping an element. This could potentially trigger action associated with element twice.
Let's say you have `onPress` and `onAccessibilityTap`, it will trigger both if you trigger action through VoiceOver.
Reviewed By: shergin
Differential Revision: D18572432
fbshipit-source-id: c5ac002317c798a10045b6f05738299d0ae27456
Summary:
Lint all files in the inspector and apply auto-fixes for licenses.
Changelog: [Internal]
Reviewed By: mhorowitz
Differential Revision: D18210914
fbshipit-source-id: 91c45d4b02a04e99dd32cf0be8771e327fe03660
Summary:
We will have several consumers for the measure infra soon (TextInput will use the same TextLayoutManager). It makes sense to move the cache there.
In the future, iOS and Android implementations will probably use a bit different (platform-specific) cache implementations because we will implement the ability to measure "opaque"/platform-specific text containers alongside with normal AttributeStrings.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D18445855
fbshipit-source-id: 7b7a65152ac13c74525da695612ae034904e82bf
Summary:
This diff makes it clear from the code that ShadowTree delegate must be around for the whole life-time of a ShadowTree instance and there is no way to revoke/reset the delegate. This makes reasoning about the lifetime much simpler.
We didn't call `setDelegate(nullptr)` before, so nothing really changes here.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D18542502
fbshipit-source-id: f57ee21e0bb533fb82cb6f8ba7723e40ffb25a38
Summary:
RCTTiming was the only NativeModule that relied on converting `double`s to other `double`s via `RCTConvert`. RCTTiming was made into a regular NativeModule in D18410788, so it's safe to strip out this logic.
Hopefully, this reduces the memory consumption enough to reduce the OOMs reported in T45151932.
Changelog:
[iOS][Removed] - Stop using RCTConvert to convert between primitive types
Reviewed By: fkgozali
Differential Revision: D18506069
fbshipit-source-id: 7316ad86bc84d47fb383735126d5b00e5491b371
Summary:
We see crashes that happen in the destructor of `EventEmitterWrapper` class which indicates that `EventEmitter`s were not "disabled" before `Runtime` was deallocated. Assuming that `Scheduler` *was* deallocated before the `Runtime` (there is no proof for that), we can suppose that `stopSurface` was not called properly on time. Again, assuming that the moment of Scheduler deallocation is fine, we can try to recover from this situation by forced unmounting of all outstanding `ShadowTree` (that will make future destroying of EventEmitter don't crash).
Why do we believe that `Scheduler` *was* deallocated before `Runtime`?
We are not sure but that's possibly a case or that might be true for some portion of cases.
At least, we will know for sure what exactly went wrong. There is a possibility that all crashes that would happen after will happen exactly here.
And, frankly, from the probability standpoint, earlier we destroy JSI objects, lower chances are that it will be after the death of Runtime.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: sammy-SC
Differential Revision: D18465408
fbshipit-source-id: 76338ed6fce0621cf11ce3178b4d1be7e0c73ccf
Summary:
Changelog: [Internal]
The main use-case here is to get the rootTag off RCTImageView, for image loading instrumentation. The fact is, each RCTView subclass already has `reactTag` attached today. We already have the `rootTag` when the view is created by the UIManager, so why not just attach it like reactTag? If we don't, looking up the rootTag from the native component is non-trivial and extremely inefficient (have to jump to shadow queue, back to main queue, etc).
Reviewed By: sammy-SC
Differential Revision: D18497002
fbshipit-source-id: 8409e3a1c95e09accedd959592cbf178fab0b2c3
Summary:
Changelog: [Internal]
For attribution purpose, pass in the surfaceId and let the app-specific image loader handle it.
Reviewed By: shergin
Differential Revision: D18494106
fbshipit-source-id: e22ca339a2dd12c5bd619b596c7db9c49dc111d0
Summary:
Simple renaming. Now the name is aligned with `SchedulerDelegate::schedulerDidFinishTransaction` and actually expresses the idea that not only commit finished but also a transaction was prepared and layout events were sent.
Changelog: [Internal] Fabric-specific internal change.
Reviewed By: mdvacca
Differential Revision: D18542503
fbshipit-source-id: 54d429ed139383621fe926fa48a4de062f724176
Valentin Shergin
Eli White
Joshua Gross
Will Holen
Sidharth Guglani
George Zahariev
Ramanpreet Nara
Samuel Susla
Riley Dulin
Kevin Gozali