Filled feedback FB22297294

This got fixed on macOS15

This bug is still present on macOS26 FB14942502

The select bundle black background has just been fixed by apple but the TestFlight section still shows wrong icons

I am able to reproduce this bug by attaching a textField into accessory view of NSSavePanel + trying to press enter. Once you move focus to the textfield and try to press enter it will print CLIENT ERROR: TUINSRemoteViewController does not override -viewServiceDidTerminateWithError: and thus cannot react to catastrophic errors beyond logging them PS: Pressing enter from accessory view worked flawlessly in macOS Ventura and below. class ViewController: NSViewController, NSTextFieldDelegate, NSControlTextEditingDelegate { let savePanel = NSSavePanel() override func viewDidLoad() { super.viewDidLoad() let customView = NSView() let textField = NSTextField(string: "11111111") textField.delegate = self // to get focus using tab keypress savePanel.accessoryView = textField } override func viewWillAppear() { savePanel.runModal() } }

The API still fails for CMYK jpg when the compression value is 1.0 (14.5). CIContext can only work with RGB -> it doesn't fail. heifImageDataUsingCIContext(at: url, compressionQuality: 0.99) // 648046 bytes heifImageDataUsingCIContext(at: url, compressionQuality: 1.0) // 1058444 bytes heifImageDataUsingDestination(at: url, compressionQuality: 0.99) // 645421 bytes heifImageDataUsingDestination(at: url, compressionQuality: 1.0) // nil

From WWDC 2015 Session 232 Best Practices for Progress Reporting: NSProgress properties are key value observable Add KVO observers to update your UI Not necessarily called on main thread. I wouldn't risk doing bindings as it might crash your app.

You did your bindings wrongly. The KVO should be done on "indeterminate" instead of "isIndeterminate" progressIndicator.bind(.isIndeterminate, to: progress, withKeyPath: "indeterminate")

My problem was daemon running in background Little Snitch . Kill it/disable it + turn off wifi u/Mareks-MacBook-Pro-M1 LaunchDaemons % ls -al /Library/LaunchDaemons  total 16 drwxr-xr-x   5 root  wheel   160 May 14 13:49 . drwxr-xr-x  71 root  wheel  2272 May 15 14:50 .. -rw-r--r--   1 root  wheel   621 Apr 20  2023 at.obdev.littlesnitch.daemon.plist lrwxr-xr-x   1 root  wheel   103 Dec 17  2022 com.oracle.java.Helper-Tool.plist -> /Library/Internet Plug-Ins/JavaAppletPlugin.plugin/Contents/Resources/com.oracle.java.Helper-Tool.plist -rw-r--r--   1 root  wheel   572 Jul  6  2022 com.xk72.charles.ProxyHelper.plist

Fixed in 14.5. However something has changed internally. Count of data bytes when compressing image with 0.1 compression factor: 14.5: 37393 14.4.1: 399845 14.2: 36408 12.7.4: 36409

Same behaviour on 14.4.1. Not fixed.

Same issue is observed with TIFF

Xcode15 quicklook renders this as a one solid red color square on a P3 display, while the NSImageView displays it as a 2 different shades of red on a P3 display. let size = CGSize(width: 250, height: 250) let image = NSImage(size: size, flipped: false) { drawRect -> Bool in let rects = drawRect.divided(atDistance: drawRect.size.width/2, from: .minXEdge) NSColor(displayP3Red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0).set ( ) NSBezierPath(rect: rects.slice).fill() NSColor(red: 1.0, green: 0.0, blue: 0.0, alpha: 1.0).set() NSBezierPath(rect: rects.remainder).fill() return true } imageView.image = image

Documentation: If the pixel density or color space of the destination graphics context changes, though, the image representation throws away any caches and executes the block again to obtain a new version of the image. While the NSCustomImageRep is of Generic RGB colorspace it doesn't produce any backing cgImage. Backing cgImage is only created when needed based on destination cgContext. XCode quicklook (bug?): <<CGColorSpace 0x600001288180> (kCGColorSpaceICCBased; kCGColorSpaceModelRGB; sRGB IEC61966-2.1)> Directly asking for cgImage <<CGColorSpace 0x600002935aa0> (kCGColorSpaceICCBased; kCGColorSpaceModelRGB; Color LCD)> If you use the method to resize an image and assign it to NSImageView it will display it correctly. For this reason I wouldn't recommend using NSImage drawingHandler to resize image. The only way is to set custom context inside the drawing handler) The image representation copies the block and stores it for later use. This is a huge memory waste if it's a bitmap image rep. E.g. you have 5000x5000 image hanging around in memory.

Can you open WEBP file from disk and add it to album?