isHidden seems to be cumulative in UIStackViews, so we have to ensure to not set it the same value twice.

I think I'm facing the same issue in Mail Version 13.4 (3608.80.23.2.2) on macOS Catalina 10.15.4 (19E287).

Here is a screenshot of an email that uses an embedded GIF to display a purple arrow.

https://user-images.githubusercontent.com/198988/82755471-fb6b6080-9dd3-11ea-81b9-b7c098628727.png

As in OPs case, this embedded arrow GIF also has quite a width of 1800px so it can be scaled down with CSS. As you can see the image unexpectedly overflows its parent container to the left.

If however I link the image from an external URL instead of embedding it, the layout comes out correctly:

https://user-images.githubusercontent.com/198988/82755558-92381d00-9dd4-11ea-9c27-6ec255c4bfb3.png

I too have noticed that if I keep increasing the Mail window width enough, probably so that Mail thinks its viewport is now large enough to fit the arrow GIF, the embedded image snaps in place. For this particular email and GIF, this happens at a window width of 3600px.

Faced with the same problem

This still appears to be an issue for us on iOS 12.4

https://postimg.cc/YLt2Yb9w

https://postimg.cc/rzG9SJjZ

Faced with the same problem

This is fixed as of macOS 10.14.4 beta 3 (18E194d)

Still present in Xcode 11.4.

@JBernal possibly seeing the same issue, but unable to get the suspect text. It looks like the original attachment has expired; are you able to re-upload the sample? Thanks!

To clarify the behavior at totalUnitCount = 0, completedUnitCount = 0.

Code:

let progress = Progress(totalUnitCount: 0) progress.completedUnitCount = 0 // default print("totalUnitCount: (progress.totalUnitCount)") print("completedUnitCount: (progress.completedUnitCount)") print("isIndeterminate: (progress.isIndeterminate)") print("fractionCompleted: (progress.fractionCompleted)") print("isFinished: (progress.isFinished)")

Output:

totalUnitCount: 0 completedUnitCount: 0 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

So the header (NSProgress.h) documentation is correct, except for for "Setting both totalUnitCount and completedUnitCount properties to zero indicates that there is no progress to track; in this case, the isIndeterminate property returns false". This part actually matches the generated documentation.

Some other cases of indeterminate progress:

totalUnitCount: -1 completedUnitCount: -1 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

totalUnitCount: -1 completedUnitCount: 0 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

totalUnitCount: -1 completedUnitCount: 1 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

totalUnitCount: 1 completedUnitCount: -1 isIndeterminate: true fractionCompleted: 0.0 isFinished: false

Some cases of progress that is NOT indeterminate:

totalUnitCount: 1 completedUnitCount: 0 isIndeterminate: false fractionCompleted: 0.0 isFinished: false

totalUnitCount: 1 completedUnitCount: 1 isIndeterminate: false fractionCompleted: 1.0 isFinished: true

In summary, here's the documentation that would correctly reflect the current behavior (as of iOS 13.4.1):

Whether the progress being made is indeterminate. -isIndeterminate returns YES when the value of the totalUnitCount or completedUnitCount property is less than zero, as well as if both values are zero. When progress is indeterminate -fractionCompleted returns 0.0 and isFinished returns false. NSProgress is by default KVO-compliant for these properties, with the notifications always being sent on the thread which updates the property.

Did you ever get a fix for this? Driving me mad that I can't get audio to play through my iMac in TDM since the update to Mojave on my 2019 MacBook Pro 15". Please let me know if there was ever a solution given - did upgrading to Catalina fix this for you?

Hello there, Sorry if it's not an appropriate place to ask but I saw the latest sheet of device colors list which only includes up until the iPhone XR. Since a lot has changed with the release of iPhone 11 Pro's, I kinly want to ask if you have the deviceEncloserColor value of the new Midnight Green color. Thanks.

Duplicated as FB7683090

Same issue - it made sign in with magic link very difficult on our users. We were able to get a workaround using our web site and custom schemes to complete the login in the app. But, it provides a much worse experience when the links don't work as intended.

This is a problem that just seems to get worse with every windows release. Unfortunately this forces my next computer purchase to be a windows laptop not another macbook just so I can continue to run windows.

    let invalidUrlCausingCrash = URL(string: "mailto:bugreport@apple.com")!
    let recorder = try? AVAudioRecorder(url: invalidUrlCausingCrash, settings: [:])

// Causing crash: *** CFEqual() called with NULL first argument ***
// in CFEqual.cold.1 ()
// Expecting throw error instead of a crash

My response to Apple:

Thank you for letting me know about the change in read size limits. I’m able to successfully read data in 4 MB chunks.

Can you confirm if the fastest way to read the entire file is to request the next chunk in the completion handler, thus ensuring that there’s at most one 4MB request in flight at a time?

Using that approach (requesting the next chunk in the completion handler), I can read a 50 MB raw image in ~0.9 seconds. [Hardware details included below.]

In comparison, when picking the same SD card using UIDocumentPicker and manually traversing the filesystem to find images, I can read the same ~50 MB raw image in ~0.002 seconds (but, with memory mapped I/O: Data(contentsOf: urlToRawImageFileOnSDCard, options: [.alwaysMapped])).

Is there a way to approximate the performance of using memory mapped I/O with ImageCaptureCore? This is important for my use case: my app is not “importing” images into a library; instead, it’s using the Vision framework to analyze images on a connected camera device, and is greatly improved by the ability to get underlying data into a UIImage as quickly as possible (regardless of where the bytes actually live).

The several-orders-of-magnitude speed difference between UIDocumentPicker and ImageCaptureCore is very significant to app responsiveness and overall utility. Unfortunately, UIDocumentPicker presents user experience challenges (it’s confusing for the user to know what files/folders to select, and it is unreliable: occasionally, enumerating the files/folders on an SD card returns no results, among other issues). ImageCaptureCore has direct camera support, notifications for added/removed devices, etc., but the performance is prohibitive for this use case.

For reference, hardware details:

• iPad Pro (11”, 1st Generation)
• Apple USB-C to SD Card Reader (UHS-II)
• SanDisk 64GB Extreme Pro SDXC (UHS-I, 170 MB/s)

For posterity, when using UIDocumentPicker to read raw images from the filesystem without using memory mapping, it takes ~0.8 seconds, which is close to the performance of ImageCaptureCore’s requestReadData(atOffset:length:completion:).)

Response from Apple:

"Please limit read size requests to < 4MB. We will be documenting this shortly."

I finally found a fix for that, at least for my use case (NSAttributedString with options [.documentType: NSAttributedString.DocumentType.html] and css)

If I set "-apple-system" it seems to use SF font:

<style type="text/css">body { font-family: '-apple-system', '\(font.fontName)', '\(font.familyName)'; font-size: \(font.pointSize)px; }</style>

Ecxelent.