* Fix resizeMode="cover" when image is resized
Since `RCTResizeModeCover` is implemented manually on macOS (iOS benefits from `UIViewContentModeScaleAspectFill` API), we need to reprocess the image any time the bounds of the view update. The `updateImage:` method was already called on resize, so this instead stores the original image in an ivar so it can call `RCTFillImagePreservingAspectRatio` from `updateImage:` instead.
* Fix rendering template images with tintColor
This fixes a regression introduced by the previous commit, where images would no longer render with the `tintColor` on release builds. We must call `setTemplate:` (using `.template` property is illegal in Objective-C++ since `template` is reserved in C++) on the newly resized image instead of the original image.
Confirmed icons look correct in the release build of Messenger Desktop.
Co-authored-by: Scott Kyle <skyle@fb.com>
We ran into an issue that our production app was crashing on certain devices as we opened too many file descriptors (> 256). See some details here: https://wilsonmar.github.io/maximum-limits/
We found that macOS will keep image files handles open for `NSImage` lifetime in some cases:
```
// this will keep file open only if image is loaded from app bundle
NSString *path = [[NSBundle mainBundle] pathForResource:@"slider" ofType:@"png" inDirectory:@"assets"];
_image = [[NSImage alloc] initWithContentsOfFile:path];
// this will not keep file open
_image = [[NSImage alloc] initWithContentsOfFile:@"/Users/theUser/Downloads/slider.png"];
// this will not keep file open
NSData *data = [NSData dataWithContentsOfFile:path];
_image = [[NSImage alloc] initWithData:data];
```
This can be documented behavior, but I didn't find any reference in documentation or headers.
Test Plan:
- build and run prod version of app
- explore open files for Messenger process in Activity Monitor
- confirm no assets are open
Co-authored-by: Scott Kyle <skyle@fb.com>
There are use cases in which we want to ignore the base class [NSTextView readablePasteboardTypes] return values, which mostly, include RTF and formatted URL types
We want to ignore them in favor of plain text (NSPasteboardTypeString).
This change allows to opt into a custom list of supported paste types.
This is a follow-up to https://github.com/microsoft/react-native-macos/pull/1350
This brings macOS parity with react-native-windows https://github.com/microsoft/react-native-windows/pull/7333 for MultilineTextInput fields
See react-native-windows PR for desired feature set.
We can't do it for SinglelineTextInput fields (at least not w/o hacks) as it does not support overriding the keyDown event :-(
https://stackoverflow.com/a/6076492
Co-authored-by: Alex Chiu <ackchiu@fb.com>
* add pull yml
* match handleOpenURLNotification event payload with iOS (#755) (#2)
Co-authored-by: Ryan Linton <ryanlntn@gmail.com>
* [pull] master from microsoft:master (#11)
* Deprecated api (#853)
* Remove deprecated/unused context param
* Update a few Mac deprecated APIs
* Packing RN dependencies, hermes and ignoring javadoc failure, (#852)
* Ignore javadoc failure
* Bringing few more changes from 0.63-stable
* Fixing a patch in engine selection
* Fixing a patch in nuget spec
* Fixing the output directory of nuget pack
* Packaging dependencies in the nuget
* Fix onMouseEnter/onMouseLeave callbacks not firing on Pressable (#855)
* add pull yml
* match handleOpenURLNotification event payload with iOS (#755) (#2)
Co-authored-by: Ryan Linton <ryanlntn@gmail.com>
* fix mouse evetns on pressable
* delete extra yml from this branch
* Add macOS tags
* reorder props to have onMouseEnter/onMouseLeave always be before onPress
Co-authored-by: pull[bot] <39814207+pull[bot]@users.noreply.github.com>
Co-authored-by: Ryan Linton <ryanlntn@gmail.com>
* Grammar fixes. (#856)
Updates simple grammar issues.
Co-authored-by: Nick Trescases <42704557+ntre@users.noreply.github.com>
Co-authored-by: Anandraj <anandrag@microsoft.com>
Co-authored-by: Saad Najmi <saadnajmi2@gmail.com>
Co-authored-by: pull[bot] <39814207+pull[bot]@users.noreply.github.com>
Co-authored-by: Ryan Linton <ryanlntn@gmail.com>
Co-authored-by: Muhammad Hamza Zaman <mh.zaman.4069@gmail.com>
* remove boost-for-react-native
* remove more
* remove pull
* add back header search path
Co-authored-by: pull[bot] <39814207+pull[bot]@users.noreply.github.com>
Co-authored-by: Ryan Linton <ryanlntn@gmail.com>
Co-authored-by: Nick Trescases <42704557+ntre@users.noreply.github.com>
Co-authored-by: Anandraj <anandrag@microsoft.com>
Co-authored-by: Muhammad Hamza Zaman <mh.zaman.4069@gmail.com>
This adds an `onPaste` event for `MultilineTextInput` that is fired when a pasting into the input, and includes the same `dataTransfer` info as the `onDrop` callback which is discussed here https://github.com/microsoft/react-native-macos/issues/842
This also fixes a typo in the API name
```onPaste``` exists atm only for macOS, but we have the corresponding change to also add it rnw if that is desired
Should we also add a property ```pasteTypes``` similar to drag&drag drag(ged)Types?
Co-authored-by: Scott Kyle <skyle@fb.com>
This allows `MultilineTextInput` to also accept and respond to the same drag and drop props as `View` (and as SingleLineTextInput) which is discussed here https://github.com/microsoft/react-native-macos/issues/842
Co-authored-by: Scott Kyle <skyle@fb.com>
* Fixing setting focus when RCTView is not yet in window
I have a scenario where I send the `focus` command to a component from it's `componentDidMount` lifecycle, which leads native code to try to set focus to a RCTView with a zero frame (okay...) that isn't in a window (also seems unexpected).
I see there's existing code that tries to deal with this for a particular RCTBaseTextInputView, but nothing generically for RCTView. I'm trying to extend that to the RCTView. As part of that, I considered using the existing pending focus flag, but that seems suspect because we could have multiple views competing for focus -- so I am opting to change it to a single, weak ref for the currently *pending* focus view (which we clear if someone else grabs, or attempts to grab focus, or if the pending view later resigns focus, in addition to the scenario already handled viz. pending focus view gets focus).
I have been able to validate these changes against 0.66 for my scenario.
* add diff tags
* add tester app page to demo (and test) focus issue
* update tags to reference new issue
* fix flow + lint
* Fix tags
Co-authored-by: Navneet Kambo <nakambo@nakambo-mm.guest.corp.microsoft.com>
Co-authored-by: Saad Najmi <sanajmi@microsoft.com>
This extends the ability to intercept `keyDown` and `keyUp` events to `TextInput`.
We need this for the ability to insert newlines when holding shift in chat, along with support arrow up/down from the search input.
Co-authored-by: Scott Kyle <skyle@fb.com>
Co-authored-by: Saad Najmi <sanajmi@microsoft.com>
Allow to render a scrollView's content in inverted order which is especially helpful in messaging applications.
We can't rely on -1 scale hacks on macOS because of inverse issues with trackpad/scrollwheel, dragging scrollbars, tracking hovers, etc.
Hence we added 'native' support for inverted views
Co-authored-by: Scott Kyle <skyle@fb.com>
* Revert "Use execFileSync over execSync when messing with file paths in generate-artifacts.js"
This reverts commit d68d2095e9.
* [RN][macos] Don't try and build Fabric example when USE_CODEGEN_DISCOVERY=1
* use `execFileSync` for secure argument passing
* Fix tag comments
* Don't use template literals as arguments
Co-authored-by: Shawn Dempsey <shawndempsey@fb.com>
Messenger Desktop is a multi-window application (chat, calling, settings, …) and we maintain the various windows with a windowNativeModule which allows JS interaction.
When receiving deep-links from other apps we don’t want to necessary re-open the lastWindow open as the deep-link might contain information about a particular scenario (open login page, start a call). Hence, we need to disable this behavior app wide and use our windowNativeModule to forward the specific window related to the deep link.
- This change has 0 effect on other apps
- We could make this property an ivar, but then we need to manually register RCTLinkingManager.mm ….
- We could append a special url property to deep-links, but I think that would make the ‘API’ harder to use`
Adam Gleitman
chiuam
Christoph Purrer
Adam Gleitman
Saad Najmi
rasaha91
Ranesh Saha
Navneet Kambo
lyzhan7
Shawn Dempsey
Mike Schreiber
Mike Schreiber