Summary:
By default, Nodes causes views to not be clipped, unless overflow is
explicitly set to hidden. Consequently, Nodes sets all the clipping bounds to
negative infinity, and does some extra work (saving the canvas layer,
clipping, etc) before drawing. This optimization skips the extra work when
it's not needed.
Reviewed By: sriramramani
Differential Revision: D3161268
Summary:
Initially, we used to mount nodes to Views anytime a node was
clicked. This was not useful, since we could still not handle touch when
a touch event was already dispatched. Later, a fix was pushed that
supported handling touch events for non-View NodeRegions. Part of the
intention was to remove this code, but it was forgotten.
Reviewed By: sriramramani
Differential Revision: D3160532
Summary: This allows users of the API to have greater control over handling RTL. One example is Components which needs this greater control to correctly handle RTL.
Differential Revision: D3120721
Summary:
UIImplementation has a few methods that in the end touch native Views, such as dispatchViewManagerCommand, addAnimation, sendAccessibilityEvent etc. There are 2 cases where it is possible to have those methods called on shadow nodes that don't have backing Views created:
- backing view is scheduled to be created but not commited yet (StateBuilder accumulates createView commands into a queue and flushes it in the very end)
- shadow node doesn't mount to a View so there is no backing View
Touching View in UI thread in these 2 cases will either lead to silent error (e.g. failure callback will execute), or a native crash.
This diff is overriding all UIImplementation methods that touch Views in UI thread and makes sure that backing View is created before we do so.
Reviewed By: ahmedre
Differential Revision: D3046392
Summary: In some rare cases, RCTText.measure can receive negative width which will crash with an assertion in android.text.Layout because it expects a positive value. This is a temporary fix to treat negative values as unconstrained width until the original bug is fixed.
Reviewed By: sriramramani
Differential Revision: D3038767
Summary:
Since we now have the correct fix in place, this patch is to revert
the hack we put in place to not be launch blocking.
Reviewed By: sriramramani
Differential Revision: D3019883
Summary: In FlatViewGroup, we flatten some react nodes into parent while mounting others into child Views. This is causing touch events being dispatched to wrong targets because child Views are \"stealing\" touch events from flattened Views. To fix the issue, implement ReactCompoundViewGroup to provide information about both virtual and non-virtual nodes.
Reviewed By: ahmedre
Differential Revision: D3018054
Summary: Before this patch, we only collected virtual nodes in NodeRegions, because NodeRegions are only needed to implement ReactCompoundView.reactTargetForTouch() which is only interested in virtual nodes. In the next patch, FlatViewGroup will implement ReactCompoundViewGroup interface which requires knowledge of both virtual and non-virtual children. As a step towards that, we need to include non-virtual nodes in NodeRegions. This patch is implementing that. By itself, it should have not cause any changes in application behavior: we add non-virtual nodes to NodeRegions and mark them as non-virtual, then skip all non-virtual nodes in reactTagForTouch().
Reviewed By: ahmedre
Differential Revision: D3018047
Summary: Before the patch, order of NodeRegions was inconsistent. Given parent A and 3 children B, C and D, we collect DrawCommands like this: A, B, C, D but NodeRegions were collected as B, C, D, A which neither matches draw order, nor a reverse of it. This patch changes it so that NodeRegions are collected in drawing order (A, B, C, D) and we iterate backwards to find correct touch target (in case they overlap).
Reviewed By: ahmedre
Differential Revision: D3018034
Summary:
This is a hack to fix the Groups dialog bug so that we can get some
real data in production from using Nodes. This should be replaced with a
better solution in the near future.
Differential Revision: D3016859
Summary: CSSNode.addChildAt() calls dirty() to invalidate the node and propagate dirty flag up to the root. However, ReactShadowNode overrides dirty() for virtual nodes so it does nothing. This results in bugs where an added text doesn't trigger a measure pass because RCTText is never dirtied. To fix the bug, override addChildAt() in RCTVirtualText and explicitly call notifyChanged(true) to make sure hosting RCTText is dirtied and re-measured/re-laid out.
Reviewed By: ahmedre
Differential Revision: D3016827
Summary:
This code reverts D3004541, since it fixes the symptom instead
of the root cause. Root cause fix is in D3011191.
Differential Revision: D3011291
Summary: @public Split dispatchViewUpdates into two methods, which enables subclasses to commit pending ui operations, even when no root node is present.
Differential Revision: D3011191
Summary:
getLayoutWidth is the same as right - left, and since we have right
and left, we can save a method call.
Reviewed By: sriramramani
Differential Revision: D3010697
Summary:
In D2980358, alignment was implemented for nodes. This unfortunately
introduced a bug, which is that when we have a BoringLayout that is set to
ALIGN_CENTER, it can't be seen. This is a result of the fact that the width
passed in to BoringLayout is Integer.MAX_VALUE. Since measure has already
been called at this point, we can just pass the layout's width as the width
of the BoringLayout.
Reviewed By: sriramramani
Differential Revision: D3004971
Summary:
Groups had a crash when running with React with Nodes when returning
from a search screen. This was due to the fact that the node representing a
ShimmerFrameLayout was being dropped, and then later we were trying to detach
it. Since the view was already dropped, we shouldn't try to detach it since
it's already dropped and removed from the view hierarchy.
Reviewed By: sriramramani
Differential Revision: D3004541
Summary:
We keep a list of FlatShadowNodes that mount to Views that we want to delete, and only flush it at the end of an update cycle. This results in a situation where a root view is being removed before children are removed, which results in a crash in NativeViewHierarchyManager because a View that we are trying to remove no longer exists. There are a few approaches to fix the issue:
a) make a check if a View exists before removing it. While works, it removes a bug protection when we erroneously trying to remove a View that no longer exists (such as this). I'd prefer to keep the check in place
b) flush the views-to-drop queue. This works, but does some extra work in UI thread (namely, removing Views that would be removed anyway)
c) trim the views-to-drop queue to remove any Views that will be removed anyway. This does a tiny bit of extra work in BG thread, but less work in UI thread.
This diff implements option c).
Reviewed By: ahmedre
Differential Revision: D2990105
Summary:
Code in FlatUIImplementation.manageChildren() incorrectly assumed that moveFrom is sorted and moveTo is not, which is actually reverse: moveFrom is not sorted, and moveTo is. This means that we need to sort moveFrom before we can traverse it, and that we no longer need to sort moveTo (we did it by moving nodes to mNodesToMove first and then sorting it).
The sorting algorithm used is borrowed from Android implementation of insertion sort used in DualPivotQuicksort.doSort() when number of elements < INSERTION_SORT_THRESHOLD(32) which is 99.999% the case in UIImplementation.manageChildren() (most of the time this array is either empty or only contains 1 element).
Another (very rare) bug this is fixing is that the code only worked for FlatShadowNodes, but not all shadow nodes are FlatShadowNodes (there are rare exceptions, such as ARTShape, ARTGroup etc). New code works with all types of shadow nodes.
Reviewed By: ahmedre
Differential Revision: D2975787
Summary: We are currently traversing entire tree every time there is any update to any of the nodes, which is hugely inefficient. Instead, we can early out for nodes that are known to contain no updates. This saves a lof of CPU. This optimization can be turned off, and an Exception will be thrown if there was an unexpected update.
Reviewed By: ahmedre
Differential Revision: D2975706
Summary:
Fix screenshot tests for React with nodes. It was broken due to
calling clipRect with bounds of [-∞, ∞], which, due to a bug in Canvas that
appeared in screenshot tests, caused the view not to draw. Since this is a
no-op anyway, this patch just doesn't call clipRect when we have infinite
bounds.
Differential Revision: D2975494
Summary: Right now invalidate always tell the root node that the tree is dirty, and next update will traverse the entire tree in search of changes. While this works correctly, it's not the most efficient implementation. It is more efficient to store dirty flag in every node, and skip entire subtrees if this node and all descendants are already up to date. This diff is a first step towards that optimization.
Reviewed By: ahmedre
Differential Revision: D2955197
Summary:
Examples that use defaultValue as part of their declaration (such as
those examples under UIExplorerApp's TextInput) were being ignored. This patch
supports having text set directly on RCTTextInput and handles it properly.
Note that this patch depends on D2962643 and D2964847, without which the
TextInput example will look wrong.
Differential Revision: D2968002
Summary:
There are 2 issues in removeChild() implementation.
a) There is a chance that a node that we are removing will be mounting to a View, but the create view request has not be created so there is no backing View for it yet. In that case, FlatNativeViewHierarchyManager.dropView() will throw an Exception failing to find the View. The fix is to only dropView() if one was (requested to be) created.
b) If the shadow node that we are removing doesn't mount to a View, but one or more of its children do, those Views will leak because noone is removing them. The fix is to recursively call removeChild() until we find a node that mounts to a View.
Reviewed By: ahmedre
Differential Revision: D2974938
Summary:
OnLayoutEvent was incorrectly dispatching x/y coordinates relative to native View instead of relative to parent. This was causing issues in many cases, such as when Node was mounting to a View, in which case x/y would always be 0. This diff is fixing it.
This diff also caches last OnLayoutEvent to avoid dispatching the event on every layout even when layout didn't chance.
Reviewed By: ahmedre
Differential Revision: D2955087
Summary:
Setting the color for a TextInput with nodes was broken. The text color was
not being applied due to an optimization that prevented setting spans if
begin and end were the same (which is the case for an empty TextInput).
This patch depends on D2962643.
Differential Revision: D2962394
Summary:
The spannable flags for RCTVirtualText were always being set to
INCLUSIVE_EXCLUSIVE - this is different than the behavior that is found in
ReactTextShadowNode, which sets EXCLUSIVE_INCLUSIVE as the default flag
unless the text is at the beginning.
This is needed to fix various problems with TextInput, including the handling
of empty spans (see also D2962394 which depends on this patch), and making the
behavior consistent when styled children of a TextInput are changed.
Differential Revision: D2962643
Summary:
Implement measure for RCTTextInput. This is (almost) the same as
the one implemented for ReactTextInputShadowNode.
Differential Revision: D2964847
Summary:
There are 2 reasons why someone would call StateBuilder.ensureBackingViewIsCreated():
1) to make sure a View is created, because we are going to use it NOW
2) make sure react styles are applied to View, which doesn't really need the View to be created immediately
This diff is splitting the method into 2, without changing behavior. Difference between the methods' signatures is coming from the fact that 1) never takes styles and 2) possibly takes styles.
This is a pure refactoring diff and should have no change in functionality or behavior.
Reviewed By: ahmedre
Differential Revision: D2916697
Summary:
There is a rare case in React Native when a hierarchy is created and then *immediately* discarded all in one transaction. This is causing a View leak, because a View is created and then never attached to a hierarchy because it shadow node got detached. Since we never attached the View to the hierarchy, we cannot do a detach either and the View is kept in NativeViewHierarchyManager forever, causing a View leak. To fix the issue, don't create a backing View whenever a shadow node mounts to a View. Instead, put the create request into a queue and ONLY execute it if a shadow node is still attached to a hierarchy. This is fixing the View leak because will not create a View unless it's going to be attached somewhere.
The same logic applies to View style update (we don't want to update a View that is going to be detached from a hierarchy).
Reviewed By: ahmedre
Differential Revision: D2916826
Summary:
There are 2 reasons why someone would call StateBuilder.ensureBackingViewIsCreated():
1) to make sure a View is created, because we are going to use it NOW
2) make sure react styles are applied to View, which doesn't really need the View to be created immediately
This diff is splitting the method into 2, without changing behavior. Difference between the methods' signatures is coming from the fact that 1) never takes styles and 2) possibly takes styles.
This is a pure refactoring diff and should have no change in functionality or behavior.
Reviewed By: ahmedre
Differential Revision: D2916697
Summary:
When layout happens, left/top/right/bottom coordinates (and thus clip-*, too) are sometimes not at a pixel boundary for 2 reasons:
a) width/height in Flexbox are floats, and can contain any value, not just a whole pixel. E.g. style={{width: 3.1415926}} is perfectly valid
b) floating point arithmetics sometimes leads to values barely outside of pixel boundaries (width 18.0f can become 18.000001f when a sibling/child size changes).
a) is \"breaking\" screenshot tests, which slightly but differ from reference implementation
b) causes extra View updates/redraws for no reason
This patch is rounding DrawCommand bounds to a whole pixel to avoid these 2 issues.
Reviewed By: ahmedre
Differential Revision: D2934401
Summary:
Public
We wanted to do this before, but couldn't because touch events had timestamps
set by the system (and matched System.currentTimeMillis), but now we set those
timestamps! The idea behind this change is that System.currentTimeMillis is
unreliable, but nanoTime isn't, and it also guarantees that we will never have two events with the same
timestamp.
We're still seeing crashes with touch events not ending correctly in JS, this
might be the cause of that.
Reviewed By: foghina
Differential Revision: D2953917
Summary:
Many of StateBuilder methods take a lot of arguments, which makes it hard to read. This patch is doing a bit of cleanup by removing tag from the method signatures, because tag can be easily obtained from the node itself.
This is a pure refactoring diff and should have no functional changes.
Reviewed By: ahmedre
Differential Revision: D2915815
Summary: Both DrawView and AbstractDrawCommand have clipping logic, this diff is moving out logic into a common base class. This also reverts the screenshot tests fix, which was causing issues with overflow: visible.
Reviewed By: ahmedre
Differential Revision: D2933780
Summary:
The current AndroidView stipulates that the backing shadow node can't
be a FlatShadowNode. In some cases, however, we want to apply some of the same
logic (ex not adding NodeRegions, etc) to other ViewManagers that have a
FlatShadowNode backing (and that don't necessarily create a FlatViewGroup).
This commit renames AndroidView to NativeViewWrapper, and re-introduces
AndroidView as an interface, so that logic for padding, NodeRegions, etc can
be shared.
Differential Revision: D2942387
Summary: Not every CSSNode in a hierarchy is a FlatShadowNode, some virtual nodes can be ReactShadowNodes for compatibility with ART nodes. This diff fixes StateBuilder unconditionally casting a node to FlatShadowNode, which is causing a crash in Groups.
Reviewed By: nickholub
Differential Revision: D2941031
Summary: These methods (mostly getters/setters) are not meant to be overriden, so let's make them final. Hopefully, they will inline better, too.
Reviewed By: ahmedre
Differential Revision: D2933869
Summary:
@public Relax the constraint on ReactTextInputManager.
The TextInput Advanced screen looked different with and without
nodes, namely child Text items were not being rendered on the Nodes version.
This patch fixes that.
Differential Revision: D2930800
Summary: FlatUIImplementation.handleCreateView was missing an Override annotation. This diff fixes it.
Reviewed By: sriramramani
Differential Revision: D2919596
Summary: Currently, we wrap all unknown shadow nodes with AndroidView. This works great, except when the shadow node is virtual, i.e. it *doesn't* mount to a View. In this case, we just need to keep it in the hierarchy as is. Fixes ARTSurfaceView not working correctly in groups.
Reviewed By: ahmedre
Differential Revision: D2933325
Summary: Software Canvas uses ints to represents boundaries (because it is backed by Bitmap that has scalar size), whereas Hardware Canvas uses floats to represent boundaries. This results in a bug in Software Canvas where clipping with floats close to or outside of int range results in int overflows and incorrect clipping. To fix the issue, compute the clip boundaries manually instead of using Canvas.clipRect() method (that contains the bug).
Reviewed By: sriramramani
Differential Revision: D2919509
Summary: There is a bug in border drawing code that will not draw the border if the element has a background color. This diff fixes it.
Reviewed By: sriramramani
Differential Revision: D2919549
Summary: ImageRequestHelper was not handling data: scheme correctly, which resulted in images failing to load. This diff is fixing it by considering \"data:\" as a Uri resource, and piping it appropriately.
Reviewed By: sriramramani
Differential Revision: D2919403
Summary: Previously, RCTImageView/DrawCommand would always clip for specific scale types (such as CENTER_CROP), but this is incorrect if we want to allow overflow: visible on RCTImageView (which iOS allows). This patch tweaks the clipping condition from paddingLeft/paddingTop < 0 (i.e. image wants to draw outside of its bounds) to actual image rect being outside of clip rect. Previously, that would mean exact same thing, but now that clip rect is aware of overflow: visible, it matters, allowing RCTImage to not clip when we want it to draw outside of the boundaries.
Reviewed By: ahmedre
Differential Revision: D2873350
Summary:
Previously, every node would be clipped by its own boundaries. This made sense, because
a) RCTView cannot draw outside of its bounds, so clipping is harmless
b) all other node types were not allowed to control overflow behavior, and for them overflow was implicitly set to hidden, which means it should clip.
This diff changes the logic so that overflow can be set on any node (image, text, view etc).
The change has an important implication that make the diff a little trickier that it could be: AbstractDrawCommand clipping logic needs to be relaxed. Previously, clip bounds were *always* intersected with node bounds, which means that clip rect was always within node rect. This is no longer true, and thus shouldClip() logic needs to be modified.
Because of the above, RCTText no longer needs to artificially clip bounds against layout width/height.
Note: RCTImage is still not working with overflow: visible correctly (it still always clips). This is fixed in a follow up diff.
Reviewed By: ahmedre
Differential Revision: D2867849
Summary:
There is an assert in FlatViewGroup.reactTagForTouch() that says that TouchTargetHelper should not allow returning getId() when pointer events are BOX_NONE. This is not entirely accurate.
This acturally method is invoked in 2 different contexts. Main context is to find a touch target, and in that context the method indeed should never return getId() if pointer events are BOX_NONE. There is however a TouchTargetHelper which actually expects that reactTagForTouch() *may* return getId(), in which case it will perform logic to not all this method be invoked again from main context.
In other words, this assert needs to be removed because it is entirely possible to return getId() when pointer events are BOX_NONE. Ideally, these would be 2 different methods, but ReactCompoundView interface only defines a single reactTagForTouch() method.
Reviewed By: ahmedre
Differential Revision: D2873931
Summary: When padding is applied to RCTText, the text it renders should be offset by that padding. This is what iOS is doing.
Reviewed By: sriramramani
Differential Revision: D2872039
Summary: A simple refactoring diff that should make code a little easier to read. No functional changes.
Reviewed By: ahmedre
Differential Revision: D2867718
Summary: Exact same class is needed for Groups, and probably for other apps that want to work with Nodes, too, so let's extract it into a helper class to simplify coding.
Reviewed By: sriramramani
Differential Revision: D2873943
Summary:
Nodes create a FlatViewGroup for a root node element, and NativeViewHierarchyManager assigns it an id that matches root node it. Now this top-level FlatViewGroup is added to a ReactRootView. In non-nodes, this ReactRootView has an id that matches root View id, and when this ReactRootView gets detached from Window, it sends an event to NativeViewHierarchyManager that says that all the children of this View must be removed recursively. This works great in non-Nodes, but fails in Nodes because ReactRootView has no id (-1) and NativeViewHierarchyManager fails to find a corresponding ReactShadowNode, throwing an Exception. To fix the issue and make it work again we need to assign this View id of the top level shadow node. This creates a minor issue, where 2 Views (ReactRootView and its only child) share the same id, but that is not a problem because we don't enforce uniqueness of the ids, and don't rely on getViewById().
This was originally implemented, but then I removed it because I thought it wasn't truly needed. Turns out, it is needed.
Reviewed By: sriramramani
Differential Revision: D2873995
Summary: This diff implements ImageLoadEvents (ON_LOAD, ON_LOAD_END and ON_LOAD_START) in RCTImageView. ON_ERROR and ON_PROGRESS are easy to implement, too, but these 2 are supposed to carry extra information (error message and progress) but ImageLoadEvent doesn't support a payload yet (I'll add them in a separate patch).
Reviewed By: ahmedre
Differential Revision: D2824772
Summary: React provides properties to support shadows for Text, this diff implements it for Nodes.
Reviewed By: ahmedre
Differential Revision: D2817212
Summary: Minor optimization/cleanup: instead of creating an instance of FontStylingSpan for every RCTVirtualText, start with a global immutable instance of use copy-on-write when any of the properties change.
Reviewed By: ahmedre
Differential Revision: D2817156
Summary: Wrong order or top/right -> right/top means that clipping can be incorrect. I didn't notice it because visual result in many cases would still be the same (especially with overflow: visible being default and clipping being mostly disabled). Also only background was clipped incorrectly, and most texts don't have a background.
Reviewed By: ahmedre
Differential Revision: D2816432
Summary: Small optimization that prevents empty NodeRegions from being collected. Those will never receive touch events anyway, so why bother allocating memory and iterating over them?
Reviewed By: ahmedre
Differential Revision: D2816355
Summary: RCTText may modify its DrawCommand on collectState(), which updateNodeRegion() relies on. This means that order of the two is important: call collectState() first, followed by updateNodeRegion(). This fixes the bug where am RCTText may sometimes not respond to clicks (because its NodeRegion would be empty).
Reviewed By: ahmedre
Differential Revision: D2816295
Summary: NodeRegions are touch regions within hosting View, and while in most cases they are the same as View boundaries, there is one case where it's not true: TextNodeRegion. When mounted to a View, TextNodeRegion will have a bounds of (0,0,width,height) which is clearly different from (left,top,right,bottom). Initially I assumed they would always be the same so we could use information stored in NodeRegion (should probably be called TouchRegion) to update node's View boundaries, but it breaks RCTTextView when it mount to a View (because it would either contain incorrect bounds, or View will be laid out incorrectly). Right now touch is not working on RCTView that mounts to a View. To fix the issue, separate the 2 concepts.
Reviewed By: ahmedre
Differential Revision: D2816268
Summary: Small optimization. Once we mount a Node to a View, its NodeRegion is not used anymore with RCTText being an exception, but it will correct itself automatically upon updateNodeRegion call. This patch allows the dead object to get garbage collected.
Reviewed By: ahmedre
Differential Revision: D2816331
Summary: Alternative implementation of DrawImage using DraweeHierarchy instead of ImagePipeline directly. Yields same results, but potentially more stable. We'll run tests to measure performance of both.
Reviewed By: ahmedre
Differential Revision: D2746197
Summary:
Moves ReactProp and ReactPropGroup to `com.facebook.react.uimanager.annotations`. This is needed
so that future annotation processor can run on code inside the com.facebook.react.uimanager package.
@public
Reviewed By: astreet
Differential Revision: D2754842
Summary: View.invalidate() will not actually invalidate a View if it has width or height equal to 0. This is causing problems with overflow: visible. A quick fix applied here is to invalidate slightly larger region that the View bounds to bypass the optimization.
Reviewed By: ahmedre
Differential Revision: D2800920
Summary: Virtual shadow nodes, such as RCTRawText, RCTTextInlineImage etc cannot be mounted to a View (ViewManager will throw an Exception if we ever try to). This diff is adding a check to make sure that Exception is never thrown.
Reviewed By: ahmedre
Differential Revision: D2800869
Summary: UIImplementation.measure() can only measure shadow nodes that map to native Views. As a result of this, every time we tried to measure a shadow node that doesn't map to a View, we trigger callback with no data (to indicate an error). To fix this issue, walk up until we find a node that maps to a View, then measure that View and adjust for the bounds of a virtual child.
Reviewed By: ahmedre
Differential Revision: D2800960
Summary:
Everything (but Views) are drawn using AbstractDrawCommand (or its derivative, like DrawBorder or DrawBackgroundColor) and supports clipping properly. Views however are drawn using an assumption that Android will clip them manually. This is however not always true. One example is if an element A mounts to a View, and its parent B doesn't but has overflow: hidden and thus should clip the child.
There are 2 ways to fix this:
- pop every element that has overflow: hidden to its own View. In this case, its children will always be correctly clipped. This is however very inefficient, especially if overflow: hidden is default (which it is!) which means that almost every React element must be backed by an Android View.
- add clipping information to DrawView, similar to how AbstractDrawCommand has it.
This diff implements the latter approach.
Reviewed By: ahmedre
Differential Revision: D2792375
Summary: RootFlatShadowNode always mounts to a (top-level) View but was never marked as one that mounts to a View. This diff fixes it. Nothing in the code relied on it being marked as mounting to a View, so it worked fine. A follow up path that implements UIImplementation.measure() for nodes that don't mount to a View goes up until it finds first mounting node, and it was crashing with NPE because it tried to access RootFlatShadowNode's parent (and there isn't one).
Reviewed By: sriramramani
Differential Revision: D2800818
Summary:
React allows nesting <Image> inside <Text>, in which case it turns into an RCTTextInlineImage element. RNFeed is using it in a few places and thus we need to support it, too.
This diff implements it with InlineImageSpan (WithPipeline, and WithDrawee separately).
Reviewed By: ahmedre
Differential Revision: D2792569
Summary: D2768643 disabled View clipping of FlatViewGroup's children by calling setClipChildren(false). Turns out, instead of disabling clipping on the View this method is called on, it disables clipping on the children, instead. While we want the clipping disabled on all children that are FlatViewGroups, it also means that everyone else gets the clipping disabled as well. This has issues with ScrollView that stopped clipping its scrolling content, resulting in visual glitches. To fix the issue, manually clip all the Views that are not FlatViewGroups.
Reviewed By: ahmedre
Differential Revision: D2792411
Summary: This diff add an ImageRequestHelper class to reuse code that creates ImageRequest in both RCTImageView and (upcoming) RCTTextInlineImage
Reviewed By: ahmedre
Differential Revision: D2792548
Summary: Minor cleanup; renames BitmapRequestHelper to PipelineRequestHelper and adds BitmapUpdateListener interface. I plan reusing these classes in an upcoming RCTTextInlineImage implementation.
Reviewed By: ahmedre
Differential Revision: D2792535
Summary: AbstractDrawCommand's bounds are supposed to be the rectangle that the DrawCommand will draw into, so that it can compare bounds against clip rect bounds and reliable skip clipping when it's not needed. It is however not true for RCTText that can create text Layout that in some cases can go out of it's requested bounds (happens with TextView, too). To fix the issue, instead of passing requested bounds, pass the actual ones. In this case, AbstractDrawCommand will make sure to clip DrawTextLayout if for some reason it draws outside of the allowed boundaries.
Reviewed By: ahmedre
Differential Revision: D2786306
Summary:
@public React allows excluding certain elements from touch handling by assigning `PointerEvents` filter to them, such as BOX_NONE - this element will not receive touch but its children will, BOX_ONLY - only this element will receive pointer event and not children, NONE - neither this element nor its children will receive pointer events, and AUTO - pointer events are allowed for both this element and its children.
This diff adds PointerEvents support to flat RCTView. Most of the implementation is copied from ReactViewManager/ReactViewGroup. One small change is made to TouchTargetHelper to ensure that it works correctly with virtual nodes when their parent has PointerEvents set to PointerEvents.BOX_NONE.
Reviewed By: ahmedre
Differential Revision: D2784208
Summary: There is a small bug in DrawBorder where we forget updating color for a left border, which makes the border draw with whatever color was previously set to the Paint. This diff fixes it by updating the color.
Reviewed By: ahmedre
Differential Revision: D2779511
Summary: When setJSResponder() is called on a shadow node that doesn't mount to a View, React runtime will crash in NativeViewHierarchyManager because it will fail to find a corresponding View. To fix the issue, make sure we forceMountToView() before we call enqueueSetJSResponder().
Reviewed By: ahmedre
Differential Revision: D2779523
Summary: D2772438 removed some unused imports, and a parallel build landed that uses one of the imports. Both diffs landed and now master is broken. This diff is fixing it.
Reviewed By: ahmedre
Differential Revision: D2779442
Summary:
Prior to this patch DrawCommands weren't get clipped by parent DrawCommands at all. For example, a <View> element with size 200x200 with overflow:hidden should clip its child which is 400x400, but this didn't happen. However, if parent <View> would mount to an Android View, it would clip the child regardless of the overflow attribute value (because Android Views always clip whatever is drawing inside that View against its boundaries).
This diff is fixing these issue, implementing overflow attribute support and making clipping behavior consistent between nodes that mount to View and nodes that don't.
Reviewed By: ahmedre
Differential Revision: D2768643
Summary: I lost FlatViewGroup.verifyDrawable(Drawable) method during one of the rebases. Re-adding it now because hotspot drawable is not working without it.
Reviewed By: ahmedre
Differential Revision: D2772460
Summary: Previously, manageChildren() would throw an Exception if moveFrom != null or moveTo != null. This is obviously not correct, because no matter how rare these events are, they actually happen in practice. This diff re-implements manageChildren() to support all the cases. It does so by first removing all the elements that need to be removed. During removal, those elements that need to be moved will be temporarily put into `mNodesToMove` array. Then the next step is to add all elements (including new elements to add, and existing elements to move). There is an fast path when only one of another is present. If both types are present, they need to be sorted, first, to maintain correct orded. A similar optimization is applied to `removeChildren()`: there is a fast path when moveFrom == null and a another fast path when removeFrom == null. When both are != null, a merge sort is used (it is assumed that both moveFrom and removeFrom are sorted).
Reviewed By: ahmedre
Differential Revision: D2768689
Summary: There is an OnLayoutEvent that needs to be dispatched when a ReactShadowNode gets re-laid out. Some applications rely on it, so we should support it. This diff adds this functionality.
Reviewed By: ahmedre
Differential Revision: D2768625
Summary: RCTView has a property called nativeBackgroundAndroid that shows a ripple effect (or any other Drawable) when pressed and holded. This diff is adding support for the property.
Reviewed By: ahmedre
Differential Revision: D2768671
Summary: NodeRegion is only able to describe a rectangular region for touch, which is not good enough for text, where we want to be able to assign different touch ids to individual words (and those can span more than one line and in general have non-rectangular structure). This diff adds TextNodeRegion which inserts additional markers into text Layout to allow individual words to have unique react tags.
Reviewed By: ahmedre
Differential Revision: D2757387
Summary: Views that can contain other Views need to have their ViewManager to extend ViewGroupManager. Otherwise, it may not remove child Views correctly when a parent View is being detached. This diff is changing FlatViewManager that create FlatViewGroups (that can have child Views) to extend from ViewGroupManager.
Reviewed By: ahmedre
Differential Revision: D2768667
Summary: RCTImageView.setBorderWidth() is shadowing ShadowLayoutNode.setBorderWidths() because both are annotated with `ReactProp borderWidth`. To fix the issue, override setBorder instead (which is what LayoutShadowNode.setBorderWidths delegates to).
Reviewed By: ahmedre
Differential Revision: D2763938
Summary:
In ReactNative, we are fully controlling layout of all the Views, not allowing Android to layout anything for us. This is done by making onLayout() of the top-level View in the hierarchy to be empty. This works fine because we explicitly call measure/layout for all the Views when they need to be re-measured or re-laid out. There is however one case where this doesn't happen automatically: some Android Views such as DrawerLayout or ActionBar have children that don't have shadow nodes associated with them (such as a title in ActionBar). This results in situations where children of AndroidView will call requestLayout but they will never get relaid out, because shadow hierarchy doesn't know about them. Example: ActionBar has a seTitle method that will internally call TextView.setTitle() and that TextView will call requestLayout because its size may have changed. However, that TextView will never be remeasured or relaid out.
This diff is fixing it by keeping track of everyone who called requestLayout. Then, at the end of the update loop we go over the list a manually remeasure and relayout those Views.
Not a huge fan of how this is implemented (there MUST be a better way) but this works with least efforts. I'll see if I can improve it later.
Reviewed By: ahmedre
Differential Revision: D2757485
Summary:
There is currently a bug where we never release any Views that no longer display, still storing hard references in NativeViewHierarchyManager. This diff is fixing this bug, and here is how:
a) there is already logic in place to drop FlatShadowNodes (UIImplementation.removeShadowNode).
b) there is already logic in place to drop Views (NativeViewHierarchyManager.dropView(int reactTag) - used to private but needs to be protected so I can call it)
c) (the missing part) when we are about to drop a FlatShadowNode, check if it mount to a View (i.e. there is a View associated with that node), put it into a ArrayList. When we finished updates to a nodes hierarchy (which happens in non-UI thread), collect ids from those nodes and enqueue a UIOperation that will drop all the Views. We can either forward nodes as FlatShadowNode[], or only ids as int[]. Both should be fine, but as a rule of thumb we don't touch shadow node hierarchy from UI thread (as we don't touch Views from non-UI thread) so passing int[] is what this code is doing.
Reviewed By: ahmedre
Differential Revision: D2757310
Summary: Virtual nodes (such as RCTRawText and RCTVirtualText) have no state or node regions, don't need to be laid out, and thus should not be checked for state.
Reviewed By: ahmedre
Differential Revision: D2757089
Summary: Any padding that a FlatShadowNode is assigned by React runtime should be translated to a backing Android View so it looks correct and lays out children accordingly.
Reviewed By: sriramramani
Differential Revision: D2756562
Summary: This diff adds an `AndroidView` as a proxy for custom Views in FlatUIImplementation. Any ReactShadowNode that FlatUIImplementation doesn't recognize (because they don't extend from FlatShadowNode) will be wrapped with AndroidView to ensure that it measures and displays correctly. While not perfect, this is the easiest way to support custom Views (EditTexts, DrawerLayouts, ScrollViews etc).
Reviewed By: ahmedre
Differential Revision: D2751716
Summary: @public There are some properties, such as alpha or scale that we ONLY handle on a View level. This means that whenever we encounter a FlatShadowNode with this property, it should be mapped to a View. This diff is doing exactly this.
Reviewed By: ahmedre
Differential Revision: D2694495
Summary:
This diff pulls in my changes to css-layout algorithm. (The change: https://github.com/facebook/css-layout/pull/154)
This is a breaking change, since it adds a new `height` parameter to all measure functions.
So I've fixed all existing implementations just by adding a new unused parameter `height` - it's up to owners of these functions whether they want to use it or not.
Reviewed By: foghina
Differential Revision: D2757965
Summary: Normally, order or `measure/layout` and `onAttachedToWindow` shouldn't matter. However, `DrawerLayout` has a `boolean mFirstLayout` flag that it resets to true in `onAttachedToWindow` that makes it ignore first layout, and it leads to bugs. To fix the issue, we need to make sure that we first call `onAttachedToWindow` and only then we call `measure/layout`. The easiest way to do it is to delay measure/layout calls until all the views are attached to their parents. This diff implements the mentioned logic.
Reviewed By: sriramramani
Differential Revision: D2694973
Summary: @public There are some properties that we want to handle on a View level, as opposed to a FlatShadowNode level. For example, scale or alpha, that can be done very efficiently in hardware. Once we pop FlatShadowNode to a separate View, we need to apply these properties. This is where `BaseViewManager` comes in handy.
Reviewed By: sriramramani
Differential Revision: D2694290
Summary: @public When Android dispatches `MotionEvent` to `ReactRootView`, it needs to find a correspoding react node that should receive it. To be able to do it, we need to store boundaries of every `FlatShadowNode` in `FlatViewGroup`. Then we can iterate over node boundaries and find one that contains the touch event coordinates.
Reviewed By: sriramramani
Differential Revision: D2694197
Summary: @public This diff adds a `FlatShadowNode.forceMountToView()` method that will render its contents in it own `View`.
Reviewed By: sriramramani
Differential Revision: D2564502
Summary: @public To render `View`s inside `FlatViewGroup`, we need to pass the parent to `DrawCommand.draw()` method. Used in a followup diff.
Reviewed By: sriramramani
Differential Revision: D2564478
Summary: @public Similar to a `DrawBorder` patch, this diff adds `DrawBackground` and implements `ViewProps.BACKGROUND_COLOR` property in `FlatShadowNode` with it.
Reviewed By: sriramramani
Differential Revision: D2564466
Summary: @public Initial implementation of RCTView doesn't support borders, this diff fixes it by implementing a `DrawBorder`.
Reviewed By: sriramramani
Differential Revision: D2564424
Summary: @public Initial RCTImageView implementation only supported 'src', 'tintColor' and 'resizeMode'. This diff adds support for the rest of the properties: 'borderColor', 'borderWidth' and 'borderRadius'. `AbstractDrawBorders` class is reused in a follow up diff to draw borders for 'RCTView'.
Reviewed By: sriramramani
Differential Revision: D2693560
Summary: @public This patch adds basic support for RCTImageView (only 'src', 'tintColor' and 'resizeMode' properties are supported for now), and a concept of AttachDetachListener that is required to support it to FlatUIImplementations.
Reviewed By: sriramramani
Differential Revision: D2564389
Summary: @public This is a pure refactoring diff makes `StateBuilder` code a little bit easier to read. This gets increasingly important as new features with similar logic are added to `StateBuilder`.
Reviewed By: sriramramani
Differential Revision: D2564342
Summary: @public `RCTVirtualText` is creating a new `CustomStyleSpan` on every `applySpans()` call, which is not very efficient. We can cache and reuse unchanged `CustomStyleSpans` for efficiency. This patch is doing just that.
Reviewed By: sriramramani
Differential Revision: D2564366
Summary: @public Initial version of FlatUIImplementation lacks any primitives support (such as RCTText, RCTImageView or RCTView). This diff add the first part, RCTText (alongside with RCTVirtualText and RCTRawText).
Reviewed By: sriramramani
Differential Revision: D2693348
Summary:
Improvement over https://github.com/facebook/react-native/pull/11469.
Depends on https://github.com/react-native-community/boost-for-react-native/issues/1, **don't merge before it is fixed**.
It would be more in line with other dependencies to depend only on github for thirdparty bridge dependencies.
**Test plan (required)**
- Circle (testing with caches cleaned)
- ./gradlew ReactAndroid:packageReactNdkLibsForBuck (check twice to make sure caches work)
REACT_NATIVE_BOOST_PATH=./path-to-local-boost/
- ./gradlew ReactAndroid:packageReactNdkLibsForBuck (check twice to make sure caches work)
Closes https://github.com/facebook/react-native/pull/11511
Differential Revision: D4348098
fbshipit-source-id: 5c2f25cc395ae0cad19d56b7c0b2b102513580fb
Summary: Show a toast (since there isn't an easy way to show the yellow box)
Reviewed By: AaaChiuuu
Differential Revision: D4336435
fbshipit-source-id: 01b0dbdaabf51be3d23aab5c72ab2a701fcb8f80
Summary:
An exception is thrown when the native animation code attempts to play an animation on a view that hasn't been created yet. This can happen because views are created in batches. If this particular view didn't make it into a batch yet, the view won't exist and an exception will be thrown when attempting to start an animation on it.
This change eats the exception rather than crashing. The impact is that the app may drop one or more frames of the animation.
**Notes**
I'm not familiar enough with the Android native animation code to know whether or not this is a good fix. My team is using this change in our app because dropping animation frames is better than crashing the app. [This is the code](c612c61544/ReactAndroid/src/main/java/com/facebook/react/uimanager/UIViewOperationQueue.java (L874-L892)) that is creating the views in batches. Hopefully my PR at least provides some insight into the cause of the bug.
This may fix#9887
Closes https://github.com/facebook/react-native/pull/10907
Differential Revision: D4340129
Pulled By: lacker
fbshipit-source-id: 69160d9e71281a96a7445d764b4715a3e54c0357
Summary:
Boost is officially hosted on SourceForge which has ab SSL problem that Gradle complains about and also it is sometimes unavailable.
I switched to using npm hosted (yarnpkg mirrored for performance) boost lib exactly the same as from Source Forge.
Other alternatives considered:
- CDN e.g. mirror.nienbo.com started responding with 4XX code when requested by Gradle
- File sharing like DropBox are not for mass anonymous downloads
- Github is not good for binary files and is throttled for anonymous raw file downloads
- S3 or similar. Requires amazon account for maintenance and does not expose semver API and other nice features that npm has
In the future I'd like to try Yarn as dependency management tool for bridge builds, this could be the first step.
**Test plan (required)**
- Circle (testing with caches cleaned)
- `./gradlew ReactAndroid:packageReactNdkLibsForBuck` (check twice to make sure caches work)
- `REACT_NATIVE_BOOST_PATH=./bridge-dependencies/node_modules/boost-react-native-bundle ./
Closes https://github.com/facebook/react-native/pull/11469
Differential Revision: D4339446
Pulled By: mkonicek
fbshipit-source-id: ccc9196e9b675c16a235a318c4861aaa4e263d6e
Summary:
Android has a text API called breakStrategy for controlling how paragraphs are broken up into lines. For example, some modes support automatically hyphenating words so a word can be split across lines while others do not.
One source of complexity is that Android provides different defaults for `breakStrategy` for `TextView` vs `EditText`. `TextView`'s default is `BREAK_STRATEGY_HIGH_QUALITY` while `EditText`'s default is `BREAK_STRATEGY_SIMPLE`.
In addition to exposing `textBreakStrategy`, this change also fixes a couple of rendering glitches with `Text` and `TextInput`. `TextView` and `EditText` have different default values for `breakStrategy` and `hyphenationFrequency` than `StaticLayout`. Consequently, we were using different parameters for measuring and rendering. Whenever measuring and rendering parameters are inconsistent, it can result in visual glitches such as the text taking up too much space or being clipped.
This change fixes these inconsistencies by setting `breakStrategy` and `hyphenat
Closes https://github.com/facebook/react-native/pull/11007
Differential Revision: D4227495
Pulled By: lacker
fbshipit-source-id: c2d96bd0ddc7bd315fda016fb4f1b5108a2e35cf
Summary:
The reason for this change is to implement `allowFontScaling` on the Android's React Native Text component. Prior to this PR `allowFontScaling` only works for iOS.
The following link contains images of `allowFontScaling` working in Android on small, normal, large, and huge system fonts (from native Android display settings)
http://imgur.com/a/94bF1
The following link is a video of the same thing working on an Android emulator
https://youtu.be/1jTlZhPdj9Y
Here is the sample code snippet driving the video/images
```
render() {
const size = [12, 14, 16, 18];
return (
<View style={{backgroundColor: 'white', flex: 1}}>
<Text>
Default size no allowFontScaling prop (default true)
</Text>
<Text allowFontScaling={true}>
Default size allowFontScaling: true
</Text>
<Text style={{ marginBottom: 10, }} allowFontScaling={false}>
Default size allowFontScaling: false
</Text>
{ size.map(
Closes https://github.com/facebook/react-native/pull/10898
Differential Revision: D4335190
Pulled By: lacker
fbshipit-source-id: 0480809c44983644ff2abfcaf4887569b2bfede5
Summary:
Currently React Native is opinionated in that the easiest approach is to extend ReactActivity. However to more easily allow integrating with existing application, we should allow some of the methods in ReactNativeHost to be public, and this is a very good first step.
* There is no harm in making this public from what I can tell.
* This allows `ReactNativeHost` to be more easily used outside of the `ReactActivity` and `ReactActivityDelegate` ecosystem. (A `ReactFragment` would be a good example)
_No issues found_
**Test plan (required)**
* Run any sample app and verify it still works.
Make sure tests pass on both Travis and Circle CI.
Closes https://github.com/facebook/react-native/pull/11329
Differential Revision: D4287429
Pulled By: AaaChiuuu
fbshipit-source-id: 8cb76f3226aae3737af5f5bd6010d3eea8df9bfe
Summary:
When using React Native on Android on top of a game as an overlay, dialog windows sometimes get created with hardware acceleration disabled. This causes the UI to be unresponsive and anything that uses a TextureView stops working. Added a property for the modal view to make sure hardware acceleration flag is enabled when it's set to true.
**Test plan (required)**
set `hardwareAccelerated` property for Modal to force hardware acceleration on dialog windows on Android. Does nothing on iOS.
Closes https://github.com/facebook/react-native/pull/11421
Differential Revision: D4312912
Pulled By: andreicoman11
fbshipit-source-id: 9db6b2eca361421b92b24234b3501b5de0eecea7
Summary: This changes ReactImageView to pull the transform matrix for rounding from the scale type itself instead of a utility method that forwards to the same thing.
Reviewed By: lambdapioneer
Differential Revision: D4326549
fbshipit-source-id: 82e59e3c20f83beb1d454743e6dbbce8666de8a3
Summary:
The goal of this pull request is to make it easier for contributors to run Android tests locally, specifically the unit tests and integration tests. I added a bunch of checks to the local testing scripts that will warn you if your environment is misconfigured, and tell you how to fix it. I also updated the testing docs, so that the regular "Testing" page should be a decent resource to point people to when you are telling them "hey this pull request needs a test." Just Android, though, I haven't gotten to the iOS parts yet.
I also disabled a couple tests that seemed quite flaky while running on a local machine, and don't seem to be providing much value. In particular, the `TestId` test just hangs on my emulator a lot and has been flaky on CI in the past, so I removed about half of its test cases to make the sample app smaller. The testMetions test appears to be dependent on screen size so I commented it out.
Closes https://github.com/facebook/react-native/pull/11442
Differential Revision: D4323569
Pulled By: bestander
fbshipit-source-id: 9c869f3915d5c7cee438615f37986b07ab251f8c
Summary:
Currently any React Native apps that target API 23 or greater will crash on the first initial debug/dev build due to the overlay permission.
Sadly there isn't a concrete "request permission" baked into the Marshmallow permission system.
However, we can launch the overlay screen without starting the react app and once its turned on start the app.
- https://github.com/facebook/react-native/issues/10454 - targetSdkVersion 23 lead crash / App crash for targeting 23+
- https://github.com/facebook/react-native/pull/10479 - Add the overlay permission information / Larger discussion around targeting API 23+
- Intent to Overlay permission goes directly to the app in question, rather then the general full listing of applications. This allows a developer who is not familiar with the system to easily toggle the overlay without getting confused.
**Test plan (required)**
* Ran UIExplorer App on fresh install with Target 23
```
cd react-native
./gradlew :Examples:UI
Closes https://github.com/facebook/react-native/pull/11316
Differential Revision: D4286351
fbshipit-source-id: 024e97c08c40ee23646dd153794fcde7127b2308
Summary:
By default Android will put extra space above text to allow for upper-case accents or other ascenders. With some fonts, this can make text look slightly misaligned when centered vertically.
We have found that the effect is very noticeable with certain custom fonts on Android. On iOS the font aligns vertically as expected.
Android exposes a property `includeFontPadding` that will remove this extra padding if set to false. This PR exposes that to JS, and adds it to the documentation and UIExplorer.
Closes https://github.com/facebook/react-native/pull/9323
Differential Revision: D4266713
Pulled By: lacker
fbshipit-source-id: f9711254bc26c09b4586a865f0e95ef4bf77cf3f
Summary:
This PR fixes#11096.
I don't know enough the ReactAndroid's source code so I don't know if this is correct but I hope it is.
In a recent commit (d4b8ae7a8a), the `dispatchUpdates` method now returns a boolean to dispatch or not the `onLayout` event. This works well but if the content is unchanged, the line `nativeViewHierarchyOptimizer.handleUpdateLayout(this);` is never called. I don't know if it was intended but it was this which introduces my issue. I called this again even if the content didn't change. This was the behaviour before 0.38 so I guess I didn't break anything.
**Test plan (required)**
I tested my pretty big app with this fix and every screen is ok.
Closes https://github.com/facebook/react-native/pull/11222
Differential Revision: D4252101
Pulled By: astreet
fbshipit-source-id: 551559234631ac37245a854d81ba568f0ddb02dd
Summary:
This change suppresses access checking during reflection which makes reflection faster by decreasing its overhead.
**Test plan (required)**
My team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11204
Differential Revision: D4250790
Pulled By: astreet
fbshipit-source-id: 0ee2f40dcadccc695980fcae14fafe1050acb52f
Summary:
Suppose that the user is scrolled to the bottom of a ScrollView. Next, the ScrollView's content is edited such that the height of the content changes and the current scroll position is larger than the new height of the content. Consequently, the user sees a blank ScrollView. As soon as the user interacts with the ScrollView, the ScrollView will jump to its max scroll position.
This change improves this scenario by ensuring that the user is never staring at a blank ScrollView when the ScrollView has content in it. It does this by moving the ScrollView to its max scroll position when the scroll position after an edit is larger than the max scroll position of the ScrollView.
Here are some pictures to illustrate how this PR improves the scenario described above:
![image](https://cloud.githubusercontent.com/assets/199935/20408839/0e731774-accc-11e6-9f0a-3d77198645e9.png)
![image](https://cloud.githubusercontent.com/assets/199935/20408844/12877bb6-accc-11e6-8fe2-1c1bb26569cc.png)
**Test plan (require
Closes https://github.com/facebook/react-native/pull/11000
Differential Revision: D4250792
Pulled By: astreet
fbshipit-source-id: 940fff6282ad29c796726f68b4519cbdabbfe554
Summary:
ReactAndroid/build.gradle downloads a number of ad-hoc dependencies from the internet such as boost, JSC headers, and folly. Having the build depend on the internet is problematic. For example, if the site hosting the JSC headers was to go down, then CI builds would start failing.
This change introduces the environment variable REACT_NATIVE_DEPENDENCIES which refers to a path. Developers can pre-download all of the ad-hoc dependencies into that path and then the build process will grab the dependencies from that local path rather than trying to download them from the internet. This solution is in the spirit of the existing REACT_NATIVE_BOOST_PATH hook.
**Test plan (required)**
This change is used by my team's app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11195
Differential Revision: D4247080
Pulled By: mkonicek
fbshipit-source-id: 7c4350339c8d509a829e258d8f1bf320ff8eef64
Summary:
Made modification to react-native code that reduces the communication channel overhead to ~50% of prior, in some cases, by caching the class-name of the java-script module/interface.
For me it reduced the run-time of the RCTDeviceEventEmitter.emit function from 1438ms to 715ms, over a period of 8 seconds in my Android app. My project requires many emit calls, as I'm transferring real-time EEG data from a Muse headband to my react-native UI to be graphed, so this optimization was very helpful in my case.
Closes https://github.com/facebook/react-native/pull/11118
Reviewed By: astreet
Differential Revision: D4232794
Pulled By: javache
fbshipit-source-id: 25ca1cfc170a343e71ff8915c3fa7e38884a402b
Summary:
The `FrescoModule` supports providing a custom image pipeline configuration. This module is created by `MainReactPackage` but `MainReactPackage` doesn't expose any way to customize the Fresco configuration. This change adds a parameter to `MainReactPackage`'s constructor so that the `FrescoModule`'s configuration can be customized by the app. A couple of design choices were made in this change:
- `MainReactPackage`'s new constructor parameter is a `MainPackageConfig`. Introducing `MainPackageConfig` enables `MainReactPackage` to nicely support new optional configuration options in the future. Imagine the alternative of each optional configuration being a separate parameter to the `MainReactPackage` constructor.
- `FrescoModule` exposes its default configuration as a builder object through the `getDefaultConfigBuilder` method. This enables app's to start with `FrescoModule`'s default configuration and then modify it.
**Test plan (required)**
Verified that passing a custom config based on React Nati
Closes https://github.com/facebook/react-native/pull/10906
Differential Revision: D4237054
Pulled By: mkonicek
fbshipit-source-id: 8a62a6f0e77ca5f6d35238950094686756262196
Summary:
"com.facebook.react.ReactPackage" is imported twice so fixed it to once.
Closes https://github.com/facebook/react-native/pull/11165
Differential Revision: D4236961
Pulled By: mkonicek
fbshipit-source-id: 84765dd9f8731b978972959f3825bf3c9c0684e3
Summary:
When using text inputs inside a ScrollView with `keyboardShouldPersistTaps=false` (default behavior) tapping another text input dismisses the keyboard instead of keeping it open and focusing the new text input which I think is the better and expected behavior.
See #10628 for more discussion about that. Note that this affects nothing but the behavior with text inputs unlike #10628.
cc satya164 MaxLap ericvicenti
Closes https://github.com/facebook/react-native/pull/10887
Differential Revision: D4178474
Pulled By: ericvicenti
fbshipit-source-id: 0c62ea2fac0017d559d1f8674b0a686a5e1b3d2d
Summary:
This PR removes dependency to Jackson third-party library in Android React Native.
Looking at some older PRs that got merged, it seems like some work had already been done to move away from Jackson.
Anyway, there was only two classes left with a dependency on Jackson. I refactored the code to use android built-in `JsonReader` and `JsonWriter` classes instead.
Prep work was done in https://github.com/facebook/react-native/pull/10516 introducing a few unit tests around serialization, to make sure that refactoring around serialization would not break things.
All references to Jackson in build systems files (BUCK files & build.gradle) have also been removed now that no code depend anymore on this third-party library.
Motivation behind this work is that third-party dependencies in Android React Native can prove to be a pain when trying to integrate React Native components into an already existing large Android application (I know this is not the most common use case for react-native ... yet ;P), that might a
Closes https://github.com/facebook/react-native/pull/10521
Differential Revision: D4226705
Pulled By: mkonicek
fbshipit-source-id: e3a7430a79dd00c871ba3c6a705b0b0c3ec3a701
Summary:
Expose aspectRatio style prop from css-layout to React Native.
This means the following will now work:
<View style={{backgroundColor: 'blue', aspectRatio: 1}}/>
Reviewed By: javache
Differential Revision: D4226472
fbshipit-source-id: c8709a7c0abbf77089a4e867879b42dcd9116f65
Summary:
Downloading from the CDN is much faster than from SourceForge, both on my home WiFi and at the office.
I checked using the `diff` utility that both files are identical.
**Test Plan**
Circle CI build on this PR.
Closes https://github.com/facebook/react-native/pull/11087
Differential Revision: D4226538
fbshipit-source-id: a30ec1d94fe3228342c4a198bf65df7a95e0c005
Summary:
On Android, if there is a small amount of space available around a text input (e.g. landscape orientation on a phone), Android may choose to have the user edit the text inside of a full screen text input mode. This behavior isn't always desirable. For example, if your app offers some UI controls for controlling the formatting of the text, you want the controls to be visible while the user is editing the text. This Android feature conflicts with that desired experience because the UI controls would be hidden while the text is being edited.
The `disableExtractUI` prop enables developers to choose whether or not Android's full screen text input editing mode is enabled. When this prop is true, Android's `IME_FLAG_NO_EXTRACT_UI` flag is passed to the `setImeOptions` method.
**Test plan (required)**
Verified `disableExtractUI` works for both `true` and `false` values in a test app.
My team is also using this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10900
Differential Revision: D4226483
Pulled By: mkonicek
fbshipit-source-id: 8f1055f6e612b05bafabe6f07a3705dd8788e3da
Summary:
When native events where handled they were not sent to JS as an optimization but this caused some issues. One of the major one is touches are not handled properly inside a ScrollView with an Animated.event because it doesn't receive scroll events so it can't cancel the touch if the user scrolled.
Closes https://github.com/facebook/react-native/pull/10981
Differential Revision: D4226403
Pulled By: astreet
fbshipit-source-id: 41278d3ed4b684af142d9e273b11b974eb679879
Summary:
Virtual shadow nodes (e.g. text) don't use CSSNodes so we don't need to create them. This shows large savings in CSSNodes allocated, depending on the app.
This could be breaking if:
- You have virtual nodes that still set and get CSS properties. The setters now no-op for virtual nodes (I unfortunately couldn't remove them completely -- see the comment on LayoutShadowNode), but the getters will NPE. If you see these NPE's, you should almost definitely be using your own datastructure instead of a CSSNode as virtual nodes will not participate in the layout process (and the CSSNode is then behaving just as a POJO for you).
I do not anticipate this to be breaking for anyone, but am including breaking in the commit message since this is a change in API contract.
Reviewed By: emilsjolander
Differential Revision: D4220204
fbshipit-source-id: b8dc083fff420eb94180f669dd49389136111ecb
Summary:
When tapping on a link in a WebView with an unknown scheme, the app would crash. For example, if you have the link "something://example/" but your device doesn't have anything to handle the "something" scheme, the app would crash when the user clicks on the link. This change handles the exception to prevent the app from crashing. Instead, the click is a no-op and the WebView doesn't navigate anywhere.
**Test plan (required)**
Verified the app no longer crashes when clicking on unknown schemes in a test app. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10903
Differential Revision: D4226371
Pulled By: mkonicek
fbshipit-source-id: a6d3957806c6063e74fe055b0979cb9d1ce40e51
Summary:
The only callsite of `coalesce` looks like this:
```
newEvent.coalesce(oldEvent);
```
The default `coalesce` implementation returns the event with the most recent timestamp. When the events have the same timestamp then, using the variable names from above, `coalesce` returns `oldEvent`.
This change updates `coalesce`'s implementation to make it explicit that it returns `this` (`newEvent` in the variable names from above) in the case of a tie.
The motivation for this change is related to scroll events. In my team's app, we were seeing scroll events being emitted with the same timestamp and the coalescing logic was causing the oldest scroll event to be chosen. This was causing our JavaScript code to receive stale scroll information and the way the JavaScript code utilized this stale scroll information resulted in the ScrollView settling on the wrong scroll position.
**Test plan (required)**
Verified that scroll events work properly in a ScrollView in a test app. Also, my team's app uses this
Closes https://github.com/facebook/react-native/pull/11080
Differential Revision: D4226152
Pulled By: andreicoman11
fbshipit-source-id: d28a2569225ca95de662f2239a0fa14de0540a7d
Summary:
TextInput rounds padding down with `floor` when measuring. However, it rounds padding up with `ceil` when rendering.
This change makes things consistent by moving TextInput's rendering code to use `floor` as well. It looks like this is the intended behavior because commit bdff10b moved measuring from `ceil` to `floor`. It looks like TextInput's rendering code was just overlooked in that commit.
**Test plan (required)**
Verified TextInput padding works in a test app. Also, my team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/11003
Differential Revision: D4220855
Pulled By: mkonicek
fbshipit-source-id: 95349867ef89c021a8441b383a09052ca0dd569c
Summary:
Added an experimental feature to allow to use only rounded values. See #184. It's not a perfect solution and definitely can be further improved. I'm looking forward to your ideas.
Closes https://github.com/facebook/css-layout/pull/256
Reviewed By: splhack
Differential Revision: D4214168
Pulled By: emilsjolander
fbshipit-source-id: 6293352d479b7b4dad258eb3f9e0afaa11cf7236
Summary: Adds a pool to recycle CSSNodes within UIManager. A follow-up diff will hook this up to a memory pressure listener to drop the pool on memory pressure.
Reviewed By: emilsjolander
Differential Revision: D4189532
fbshipit-source-id: 46583546f71a8c59853e1dd124de31657b3c617b
Summary:
Moves from CSSNodeDEPRECATED to CSSNode. This has shown to be a huge performance win for layout time within FB.
This is BREAKING because CSSNode contains bug fixes that were not migrated to CSSNodeDEPRECATED which may change the way your layout appears. The most common of these by far involves `flex: 1`.
Previously, developers had to put `flex: 1` in many places it didn't belong in order to work around a bug in css-layout. Now `flex: 1` is treated properly and, unfortunately, this means that your layout may no longer look correct. Specifically, you may see that your layout looks collapsed, or children don't render. The fix is to simply remove `flex: 1` from those containers.
Reviewed By: emilsjolander
Differential Revision: D3992787
fbshipit-source-id: 7a3a2a34a8941c0524e6ba3c5379e434d3e03247
Summary: The java enum was recently changed from NOWRAP -> NO_WRAP so the translation from js failed. This fixes that.
Reviewed By: limichaelc
Differential Revision: D4186869
fbshipit-source-id: fe35211a6632d80356d35a01a079279ef4bd7006
Summary:
**Motivation**
Currently to use the `hitSlop` property on Android you must define the object properties `left`, `top`, `right`, and `bottom` or it will crash. iOS allows omitting object properties from the hitSlop.
This change guards and allows the `hitSlop` object properties to be optional like iOS.
**Test plan (required)**
Run the [example](f930270b00/Examples/UIExplorer/js/TouchableExample.js (L318)) and omit a hitslop property and check it does not crash.
Closes https://github.com/facebook/react-native/pull/10952
Differential Revision: D4182815
Pulled By: ericvicenti
fbshipit-source-id: 07d7aca67b5739d5d1939b257476c24dcb10cbb0
Summary: Maintains a single persistent connection to the packager for the inspector. It supports getting the available pages and connecting to them.
Reviewed By: foghina
Differential Revision: D4088690
fbshipit-source-id: 0c445225f5a3de573b199e7868c8693b78f45729
Summary: This is how we compile internally
Reviewed By: emilsjolander
Differential Revision: D4182691
fbshipit-source-id: 314b1a1ead7d299677ce7f71549c986e1b796b3b
Summary: See committed README.md. This is part of the migration to the jni implementation of CSSLayout.
Reviewed By: emilsjolander
Differential Revision: D4177009
fbshipit-source-id: f1860f5d4ffafa1375a9658227e0ac10b7df4845
Summary:
iOS supports an Image onError event. Android was firing the event but it was never reaching JavaScript because Android didn't include this event in `getExportedCustomDirectEventTypeConstants`.
**Test plan (required)**
Verified that the `onError` event now fires in a test app.
My team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10902
Differential Revision: D4180149
Pulled By: ericvicenti
fbshipit-source-id: 4bf0b9aa7dc221d838d7b6b3e88bb47196dcadef
Summary:
In the wild, our app will occasionally crash with:
```
Fatal Exception: java.lang.NullPointerException
value == null
```
The stack trace brings it back to `okhttp3.Headers$Builder.checkNameAndValue (Headers.java:316)`:
```
if (value == null) throw new NullPointerException("value == null");
```
In the proposed fix, we simply continue the documented functionality of the `extractHeaders` method by returning "null" for invalid data.
Closes https://github.com/facebook/react-native/pull/10861
Differential Revision: D4178624
Pulled By: ericvicenti
fbshipit-source-id: 632e742196339639cb57ea47f9d0efbf04f090be
Summary:
When testing an app on Android using the monkey, the monkey shouldn't be able to open or interact with the dev menu.
**Test plan (required)**
My team uses this change in our app.
Adam Comella
Microsoft Corp.
Closes https://github.com/facebook/react-native/pull/10901
Differential Revision: D4176167
Pulled By: ericvicenti
fbshipit-source-id: 8eb64715ae7496cdf957ee963777f66ab358546c
Summary: Code refactoring on the dev support class. The idea is to make the code more modular.
Reviewed By: mhorowitz
Differential Revision: D4164676
fbshipit-source-id: 0d29bdaf927cd0e9f399fe6f8e46a16dfa65fb69
Summary: Builds and ships libcsslayout.so with Android builds. This is not used yet, but a follow up diff will shortly move us from CSSNodeDEPRECATED to CSSNode (which uses libcsslayout)
Reviewed By: emilsjolander
Differential Revision: D4168140
fbshipit-source-id: d72bded88df81e4d54df31a08e4b101834770a73
Summary:
This diff makes it so ReactShadowNode holds a CSSNode instead of extending one. This will enable us to pool and re-use CSSNodes and will allow us to keep from breaking the CSSNode api assumption that nodes that have measure functions don't have children (right now, text nodes have measure functions, but they also have raw text children).
BREAKING
This diff makes ReactShadowNode no longer extend CSSNodeDEPRECATED. If you have code that depended on that, e.g. via instanceof checks, that will no longer work as expected. Subclasses that override getChildAt/addChildAt/etc will need to update your method signatures. There should be no runtime behavior changes.
Reviewed By: emilsjolander
Differential Revision: D4153818
fbshipit-source-id: 2836434dd925d8e4651b9bb94b602c235e1e7665
Summary: First step to sharing CSSLayout code between iOS and Android.
Reviewed By: emilsjolander
Differential Revision: D4160286
fbshipit-source-id: 976f5820b19a7011e0a14317c858465f932e1f59
Summary:
This diff attempts to fix a number of Android native animation bugs related to incomplete node invalidation, e.g. https://github.com/facebook/react-native/pull/10657#issuecomment-258297467.
For full correctness, we should mark any node as needing update when it is:
- created
- updated (value nodes)
- attached to new parents
- detached from old parents
- attached to a view (prop nodes)
cc/ janicduplessis
Closes https://github.com/facebook/react-native/pull/10837
Differential Revision: D4166446
fbshipit-source-id: dbf6b9aa34439e286234627791bb7fef647c8396
Summary:
This causes the step to be re-calculated on every update of min, max and step value,
to use the most up to date values for the calculation,
except if step is explicitly set to a non-zero value by the user.
Fixes#10253
**Test plan (required)**
1. Create example app
2. Create a view with a slider that has a `value`, `minimumValue` and `maximumValue` set, but no step value (or step value set to 0).
For example:
```
<Slider
maximumValue={10}
minimumValue={1}
value={4}
/>
```
3. See slider working as expected
Closes https://github.com/facebook/react-native/pull/10343
Differential Revision: D4142646
Pulled By: hramos
fbshipit-source-id: a0df87bbdbbd4b2a291d89f5579f73f517a33dfc
Summary:
This pull request exposes the `setAllowUniversalAccessFromFileURLs` method of Android WebViewSettings as a property. The reason for this is when loading pages with a `file://` baseUrl it's sometimes desirable to allow loading other assets from a file base url. (For example loading an image into a canvas). More information on its use and purpose can be found [in the android docs here](https://developer.android.com/reference/android/webkit/WebSettings.html#setAllowUniversalAccessFromFileURLs%28boolean%29)
Usage example:
``` jsx
return (
<WebView
source={{ html: myhtml, baseUrl: 'file://' }}
allowUniversalAccessFromFileURLs={true}
javaScriptEnabled={true} />
)
```
Closes https://github.com/facebook/react-native/pull/8905
Differential Revision: D4147245
Pulled By: hramos
fbshipit-source-id: 7eaa884b8c0268de52b284954a34acec0fbd4061
Summary:
`flattenOffset` has proven extremely useful, especially when dealing with pan responders and other gesture based animations, but I've also found a number of use cases for the inverse. This diff introduces `extractOffset`, which sets the offset value to the base value, and resets the base value to zero. A common use case would be to extractOffset onGrant and flattenOffset onRelease.
Closes https://github.com/facebook/react-native/pull/10721
Differential Revision: D4145744
fbshipit-source-id: dc2aa31652df0b31450556f611db43548180c7dd
Summary:
This PR updates #6851 from srikanthkh, fixing coding conventions and javadoc, and adding a test plan.
Added testing functions into the WebSocketExample page of the UIExplorer, including a tiny http server to set a cookie on demand. Instructions included in the UIExplorer app.
Closes https://github.com/facebook/react-native/pull/9114
Differential Revision: D4140534
Pulled By: lacker
fbshipit-source-id: e020ad0c6d1d3ea09c0c3564c1795b4e1bc4517d
Summary:
In the JNI portion of CSSLayout, there's a subtle bug where we were caching the jmethodid of the 'measure' of the first object that had measure called on it. However, if that class had overriden measure, then the jmethodid would be specific to that subclass's implementation and would not work for other classes. Conversely, if a regular CSSNode had been called first, then the super method would be called on the subclass instead of the proper overriden method.
Since there's not really a reason to overriden measure anyway (since you can just provide a different measure function), it's safest to just mark it final and explicitly cache the appropriate methodid
Reviewed By: emilsjolander
Differential Revision: D4132428
fbshipit-source-id: 6fb51597d80f1c03681e6611153b52b73b392245
Summary: We don't need to allocate a list for every node since leaf nodes don't have children.
Reviewed By: emilsjolander
Differential Revision: D4130818
fbshipit-source-id: 80d3e98fce9d2daa0676fd1cbed0e81edcf7adb3
Summary: This mimics (some of) the behavior we have on iOS where if you call a JS module method before the JS bundle has started loading, we just queue up those calls and execute them after the bundle has started loading.
Reviewed By: javache
Differential Revision: D4117581
fbshipit-source-id: 58c5a6f87aeeb86083385334d92f2716a0574ba1
Summary:
This diff implements ModulusAnimatedNode on Android, bringing Android up to date with JS and iOS native animation APIs.
Closes https://github.com/facebook/react-native/pull/10681
Differential Revision: D4120162
fbshipit-source-id: 4e58e1b6309c1c7a12ef835547a3f3d321c20714
Summary:
This diff implements NativeAnimation offsets on Android. Running the examples should show no change; however, calling `setOffset()` should offset the final value for any value node by that amount. This brings Android up to date with JS and iOS animation APIs.
Closes https://github.com/facebook/react-native/pull/10680
Differential Revision: D4119609
fbshipit-source-id: 96dccdf25f67c64c6787fd9ac762ec841cefc46a
Summary: This bug was introduced with the bounce-back bug fix. We need to actually set the scroll position to the max scroll position if we've gone over otherwise it can get stuck.
Reviewed By: lexs
Differential Revision: D4118084
fbshipit-source-id: 41a927a40000c526414096c9385f8bd3cbd907f3
Summary:
There was previously a race condition where hasActiveCatalystInstance would return true, but calling a JS module call on it would result in a crash. Now, hasActivtyCatalystInstance will only return true once the instance is actually accepting calls.
I'll follow this up with a more risky diff that gets rid of hasActiveCatalystInstance and just queues JS calls until runJSBundle is called.
Reviewed By: javache
Differential Revision: D4117374
fbshipit-source-id: 60941f68b0906a8213571305c564bfe3d053f51b
Summary:
This is a proposed patch for issue #7192.
Android 4.1-4.4 has support for TLS 1.1 and 1.2 but it is disabled by default. Because of the known security issues and more and more servers switching to TLS 1.2 only, it would be nice for react-native to enable this support.
I demonstrated a demo application which showcases the problem and can be used to test this patch. All sources and documentation for it can be found here:
https://github.com/bringnow/react-native-tls-test
Credits to Alex Gotev (gotev) for the nice implementation.
Closes https://github.com/facebook/react-native/pull/9840
Differential Revision: D4099446
Pulled By: lacker
fbshipit-source-id: 94db320dce6d27f98169e63f834562360c00eef7
Summary:
Followup for #5822, addressing nits.
**Test Plan**
Travis CI (the author of #5822 tested the change).
Closes https://github.com/facebook/react-native/pull/10563
Differential Revision: D4081826
fbshipit-source-id: f3a2e1996bf02f81fecea6e53fe1c522b8c85689
Summary:
**Motivation**
I'm working on a project that uses React Native and needs to add direct synchronous bindings to native stuff through the JavaScriptCore C API. This is because it's performance-sensitive and would benefit from the quickest JS->C path. It does this using cross-platform C++ code that works on both iOS and Android. Most of the infrastructure for getting access to the JSC context is already in React Native actually, just had to add a few more things.
(lexs you mentioned to tag you in this pull request)
**Test plan**
Modify the JavaScriptCore context through the `JSContextRef` returned (eg. add an object at global scope) and verify that it exists in JavaScript.
Closes https://github.com/facebook/react-native/pull/10399
Differential Revision: D4080945
Pulled By: lexs
fbshipit-source-id: 6659b7a01e09fd84475adde183c1d3aca2d4cf09
Summary:
This PR adds a few unit tests to two devsupport classes, repectively
- JSDebuggerWebSocketClient
and
- JSPackagerWebSocketClient
Unit tests do not cover all methods / branches of the code. I solely focused on testing things having to do with JSON serialization as I am considering some quick refactoring to get rid of Jackson. Just prepping safety net with these few tests before starting.
Closes https://github.com/facebook/react-native/pull/10516
Differential Revision: D4067433
Pulled By: bestander
fbshipit-source-id: 97dc356c5eca5965914be074a7175cb48f038c4c
Summary: This is a simple hook to allow native side to fetch any file under the js root folder via packager. Historically, only the `main.jsbundle` is fetched via the packager. This then allows fetching local file like a json file that lives under the same root js folder
Reviewed By: yungsters
Differential Revision: D4037730
fbshipit-source-id: a2d6eb5e30d148fee573d413fc4036d0189f4938
Summary:
In most .gradle files, lines are indented with 4 spaces, but in some places they are indented with 2 spaces. This PR fixes them and enforce it by adding .editorconfig settings.
Closes https://github.com/facebook/react-native/pull/10267
Differential Revision: D4048335
Pulled By: lacker
fbshipit-source-id: df2f2556380f56672cf85690eb1c80e640a6aedf
Summary:
Implemented 2 TODOs from ReactART for Android:
- TODO(7255985): Use TextureView and pass Surface from the view to draw on it asynchronously instead of passing the bitmap (which is inefficient especially in terms of memory usage)
- TODO(6352067): Support dashes in ARTShape
We use ReactNativeART in our Android project.
1. Our app crashes sometimes on large screen smartphones with OutOfMemoryError. Crashes happen in ARTSurfaceShadowNode where TODO(7255985) was suggested in a comment in order to use memory more efficiently.
2. We needed dashes for drawing on ARTSurface.
**Test plan (required)**
I attach a screenshot of our app which shows dashed-lines and two ARTSurfaces on top of each other rendering exactly the same as in the pervious implementation of ARTSurface.
![screenshot_2016-08-19-16-45-43](https://cloud.githubusercontent.com/assets/18415611/17811741/cafc35c4-662c-11e6-8a63-7c35ef1c5ba9.png)
Closes https://github.com/facebook/react-native/pull/9486
Differential Revision: D4021303
Pulled By: foghina
fbshipit-source-id: 880175e841e3c598013982a7748b6fc691c7e8d6
Summary:
JS API very similar to web workers and node's child process.
Work has been done by somebody else for the Android implementation over at #7020, so we'd need to have these in sync before anything gets merged.
I've made a prop `messagingEnabled` to be more explicit about creating globals—it might be sufficient to just check for an onMessage handler though.
![screen shot 2016-09-06 at 10 28 23](https://cloud.githubusercontent.com/assets/7275322/18268669/b1a12348-741c-11e6-91a1-ad39d5a8bc03.png)
Closes https://github.com/facebook/react-native/pull/9762
Differential Revision: D4008260
fbshipit-source-id: 84b1afafbc0ab1edc3dfbf1a8fb870218e171a4c
Summary:
For some reason the transitive dependency isn't picked up in OSS, so make it hard.
bestander
Closes https://github.com/facebook/react-native/pull/10397
Differential Revision: D4024350
Pulled By: bestander
fbshipit-source-id: 32182857dcc88744ebf6ce0e5cf8eaee390bf067
Summary:
We're seeing a lot of crashes from `PermissionsModule` not being able to access the current activity, mentioned in #10009 and here: https://github.com/facebook/react-native/issues/9310#issuecomment-245657347
As far as I can tell, there is no way to ensure the Activity exists since the `ReactContext` holds a `WeakReference` to the current Activity and it appears that the lifecycle calls are happening in the right order (so not the same as #9310).
This will at least allow people to catch the error in JS and update the UI or try again as opposed to crashing the app.
I'm working on some bigger changes in #10221 but this is a smaller change and important to get fixed I think.
Closes https://github.com/facebook/react-native/pull/10351
Differential Revision: D4010242
fbshipit-source-id: 7a76973bb2b3e45817d4283917740c89a10ec0b0
Summary:
We've deprecated these APIs for quite a few releases and we should be able to get rid of them now.
Remove following deprecated modules/components
- AppStateIOS
- ActivityIndicatorIOS
- IntentAndroid
- SliderIOS
- SwitchAndroid
- SwitchIOS
- LinkingIOS
Update following modules to remove callback support
- Clipboard
- NetInfo
cc bestander
Closes https://github.com/facebook/react-native/pull/9891
Reviewed By: bestander
Differential Revision: D3974094
Pulled By: javache
fbshipit-source-id: 9abe32716bd85d0cea9933894f4447d53bdd5ee7
Summary: Instead of sending a list of modules over to JS on startup (and actually blocking script execution) instead provide a proxy object that constructs each of these lazily.
Reviewed By: lexs
Differential Revision: D3936979
fbshipit-source-id: 71bde822f01eb17a29f56c5e60e95e98e207d74d
Summary:
This allows the React JS code that's running from a Service (ie GcmListenerService) to check permissions (ie check for VIBRATE permissions before delivering notifications)
**Test plan (required)**
I've run this code from a GcmListenerService subclass, and it works correctly.
Closes https://github.com/facebook/react-native/pull/10229
Differential Revision: D3980853
fbshipit-source-id: 026b1f0c953d7093b5af2bec0b4a93ebd228f62e
Summary: This way `UIImplementation` can hold on to it and use it outside of calls from the `UIManagerModule`.
Reviewed By: lexs
Differential Revision: D3899774
fbshipit-source-id: 01e4956c4540bcdf30774a3f40a625e934714ee9
Summary:
Gradle unit tests started failing, this PR fixes mockito to be one specific version instead of loose 1.+
**Explain the **motivation** for making this change. What existing problem does the pull request solve?**
Circle CI started failing without any specific reason https://circleci.com/gh/facebook/react-native/tree/master, looks like a dependency error.
Alas it is, I can reproduce the error on master with clean caches.
**Test plan (required)**
After the fix:
```
bestander-pro:react-native bestander$ ./gradlew :ReactAndroid:testDebugUnitTest
Incremental java compilation is an incubating feature.
:ReactAndroid:preBuild UP-TO-DATE
:ReactAndroid:preDebugBuild UP-TO-DATE
:ReactAndroid:checkDebugManifest
:ReactAndroid:preDebugAndroidTestBuild UP-TO-DATE
:ReactAndroid:preDebugUnitTestBuild UP-TO-DATE
:ReactAndroid:preReleaseBuild UP-TO-DATE
:ReactAndroid:preReleaseUnitTestBuild UP-TO-DATE
:ReactAndroid:prepareComAndroidSupportAppcompatV72301Library UP-TO-DATE
:ReactAndroid:prepareComAndro
Closes https://github.com/facebook/react-native/pull/10239
Differential Revision: D3968396
Pulled By: matryoshcow
fbshipit-source-id: 63374261303fb98dc252898dfd5d3b3346597e4f
Summary:
When using webview on android and trying to link to an html file located on device (using `file://`), the application would crash with an error specifying that nothing handles the fired intent. This is due to [`33a1f28`](33a1f28654) which attempts to intercept all non `http(s)` links.
This is a simple fix so hopefully it can make it into the next stable release.
Closes https://github.com/facebook/react-native/pull/9668
Differential Revision: D3956485
fbshipit-source-id: 5a752abc21802a44e3a26e88669ccb6852076992
Summary:
Android (starting from API 23) supports "light status bar", thus it is possible to extend StatusBar and make `barStyle` property work not only for iOS, but also for Android.
This PR introduces one more `barStyle` option `dark-content` in addition to two existing ones (`default` and `light-content`).
Why there are 3 options instead of 2?
Two simple reasons:
1) to make all existing applications fully compatible with these changes;
2) the default status bar on Android is dark with white text and icons, while on iOS it is light with black text and icons on it. Thus the `default` option means something like "I don't really care, just apply the default color for this platform", while two other options (`light-content` and `dark-content`) allow to accurately specify the required result.
Closes https://github.com/facebook/react-native/pull/10185
Differential Revision: D3952346
fbshipit-source-id: 999a67614abff52321fbeb06298ebf1946c3f1d1
Summary:
The hack for the status bar height is not necessary any longer, so we can remove
all code related to it
Reviewed By: lexs
Differential Revision: D3943770
fbshipit-source-id: 2d70f4ea10dd76ea6e6a73bb6edccae388bde1c0
Summary:
On tablets, using Display.getRotation() returned ROTATION_0 or ROTATION_180 when it was in landscape, not portrait as it does on phones. This resulted in the Modal being sized incorrectly on tablets. Using size and comparing width and height is the only way I can think of to figure out the device orientation and give the modal the correct size. With this change, all issues listed in #7708 should be resolved.
**Test plan**
Modal should correctly fill screen on Android phone and tablet in both portrait and landscape.
Closes https://github.com/facebook/react-native/pull/10159
Differential Revision: D3950369
Pulled By: andreicoman11
fbshipit-source-id: 9488c4302a76cc48e4f8a4026eb5770d40b6e3d2
Summary:
I noticed that the example doesn't match the definition below.
cc bestander
Closes https://github.com/facebook/react-native/pull/10175
Differential Revision: D3943967
Pulled By: bestander
fbshipit-source-id: 6941d4d663e1fd42f8723cd722eb8a5712a63dc8
Summary: Provide a base `HeadlessJsTaskService` class that can be extended to run JS in headless mode in response to some event. Added `HeadlessJsTaskEventListener` for modules that are interested in background lifecycle events, and `HeadlessJsTaskContext` that basically extends `ReactContext` without touching it. The react instance is shared with the rest of the app (e.g. activities) through the `ReactNativeHost`.
Reviewed By: astreet
Differential Revision: D3225753
fbshipit-source-id: 2c5e7679636f31e0e7842d8a67aeb95baf47c563
Summary:
This changes modal behavior to resize when the keyboard appears/disappears.
Previously, the modal would not react in any way, or it would pan above to bring the
TextInput into view. Resizing is the correct behavior for android.
This is not trivial, as in, setting the flag, because of the combination of
react native laying out all views and the system reacting to the keyboard
appearance in a weird way. Namely:
- if `windowTranslucentStatus` is not set, the system will just call
`onSizeChanged` on the dialog's content view, and everything works nicely
- with `windowTranslucentStatus` set, the system will consider the dialog as a
full screen view that doesn't resize. In order for it to resize, the base
view of the layout needs to have
`setFitsSystemWindows(true)` called on it. This is needed, so that the system
can call layout on that base view with the new value of `paddingBottom` that
coincides with the height of the keyboard. Neat.
We fix this by wrapping our existing content view (mHostView) in a simple
FrameLayout that has `setFitsSystemWindows` set. That way, `mHostView` will have
`onSizeChanged` called on itself with the correct new size of the dialog.
This has the fortunate consequence of our layout now also getting `paddingTop` as the size of the
status bar, which means that we can remove the JS `top` hack in Modal, which
was necessary for no view getting drawn under the status bar.
This behavior is set as default, since that is the default correct Android behavior.
Reviewed By: astreet
Differential Revision: D3913784
fbshipit-source-id: 4378ada21f466dc7ac6e357abeca10b88009ca3f
Summary:
After D3876927 this test started failing on CI.
Locally we can't reproduce it, and it will take some time to understand what this test is intended for so that we could remove the variable part.
More investigation will follow, t13583009
Reviewed By: emilsjolander
Differential Revision: D3930334
fbshipit-source-id: 279f67eb5a77b5d4250afd48c8b94c828da6925c
Summary:
`ReactSwipeRefreshLayout` extends `SwipeRefreshLayout` which does not play nice with Android's touch handling system.
There are two problems:
1. `SwipeRefreshLayout` overrides and swallows `requestDisallowInterceptTouchEvent`, which means that Views underneath the `SwipeRefreshLayout` will not interact correctly with parent Views of
`SwipeRefreshLayout`. We've seen this in practice by H-ScrollViews having their touches intercepted by an enclosing ViewPager. This is fixed by passing `requestDisallowInterceptTouchEvent` up to the parents of `SwipeRefreshLayout`.
2. `SwipeRefreshLayout` overrides `onInterceptTouchEvent` and never calls `super.onInterceptTouchEvent`, therefore ignoring the value of `disallowIntercept`. That means that it will intercept some touches when it
shouldn't. One such case is again the H-ScrollView, which should receive all horizontal scrolls and stop `SwipeRefreshLayout` from intercepting any touch events after scrolling. Currently, after the H-ScrollView starts scrolling, it is still possible to get the `SwipeRefreshLayout` to detect and emit refresh events. This is fixed by checking and blocking on horizontal scrolls.
Reviewed By: foghina
Differential Revision: D3929893
fbshipit-source-id: e6f8050fb554e53318a7ca564c49c20cb5137df9
Summary:
Combining 2 animated values via addition, multiplication, and modulo are already supported, and this adds another one: division.
There are some cases where an animated value needs to invert (1 / x) another animated value for calculation. An example is inverting a scale (2x --> 0.5x), e.g.:
```
const a = Animated.Value(1);
const b = Animated.divide(1, a);
Animated.spring(a, {
toValue: 2,
}).start();
```
`b` will then follow `a`'s spring animation and produce the value of `1 / a`.
The basic usage is like this:
```
<Animated.View style={{transform: [{scale: a}]}}>
<Animated.Image style={{transform: [{scale: b}]}} />
<Animated.View>
```
In this example, the inner image won't get stretched at all because the parent's scaling gets cancelled out.
Also added this to native animated implementation.
Reviewed By: foghina, mmmulani
Differential Revision: D3922891
fbshipit-source-id: 32508956c4b65b2deb7574d50a10c85b4809b961
Summary:
This fixes measuring of items in the main axis of a container. Previously items were in a lot of cases measured with UNSPECIFIED instead of AT_MOST. This was to support scrolling containers. The correct way to handle scrolling containers is to instead provide them with their own overflow value to activate this behavior. This is also similar to how the web works.
This is a breaking change. Most of your layouts will continue to function as before however some of them might not. Typically this is due to having a `flex: 1` style where it is currently a no-op due to being measured with an undefined size but after this change it may collapse your component to take zero size due to the implicit `flexBasis: 0` now being correctly treated. Removing the bad `flex: 1` style or changing it to `flexGrow: 1` should solve most if not all layout issues your see after this diff.
Reviewed By: majak
Differential Revision: D3876927
fbshipit-source-id: 81ea1c9d6574dd4564a3333f1b3617cf84b4022f
Summary:
The styles that get applied to the Dialogs that are created in RN are set in
`themes.xml`, so I'm moving `windowTranslucentStatus` there as well so that we
have all of them collocated.
Reviewed By: astreet
Differential Revision: D3913402
fbshipit-source-id: 8f23e84fb017c8810634ffe8279171061292b351