Don't recreate identical NSTrackingAreas #1971
Merged
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Please select one of the following
Summary:
We've seen an issue where mouse events sometimes behave strangely. The exact cause is unknown, but we found that one problem is that we're constantly recalculating the
NSTrackingArea
despite the fact that the size of the view isn't changing.To resolve this, we limit the recreation of a new
NSTrackingArea
to when its size would actually change.Changelog:
Pick one each for the category and type tags:
[MACOS] [FIXED] - Remove unnecessary recreation of NSTrackingAreas
Test Plan:
This was tested with the following test component in RNTester (not included as part of this change):
I validated that the
NSTrackingArea
is correct by moving the mouse into the view from all four sides. This even holds between scrolls within RNTester, moving the window, and resizing the window. Furthermore, when resizing the window,-updateTrackingAreas
only gets called once we release the mouse button and we finalize the new window size.