Post

Replies

Boosts

Views

Activity

macOS 26 beta 4 and iOS 26 beta 4 - WebKit XML parser crashes parsing XHTML with namespaces
Our app, VitalSource Bookshelf, is an EPUB reader that uses a WKWebView to display book content. The EPUB content format is XHTML and uses namespaces (for the epub:type declaration). On beta 4, the webkit process repeatedly crashes when loading our content. The crash appears to be in the XML parser. Here's what's at the top of the stack trace: 0 WebCore 0x19166a878 WebCore::XMLDocumentParser::startElementNs(unsigned char const*, unsigned char const*, unsigned char const*, int, unsigned char const**, int, int, unsigned char const**) + 4968 1 libxml2.2.dylib 0x19c5a2bd0 xmlParseStartTag2 + 3940 2 libxml2.2.dylib 0x19c59e730 xmlParseTryOrFinish + 2984 3 libxml2.2.dylib 0x19c59d8e4 xmlParseChunk + 708 4 WebCore 0x191668ec8 WebCore::XMLDocumentParser::doWrite(WTF::String const&) + 636 5 WebCore 0x191665b78 WebCore::XMLDocumentParser::append(WTF::RefPtr<WTF::StringImpl, WTF::RawPtrTraits<WTF::StringImpl>, WTF::DefaultRefDerefTraits<WTF::StringImpl>>&&) + 304 6 WebCore 0x190105db0 WebCore::DecodedDataDocumentParser::appendBytes(WebCore::DocumentWriter&, std::__1::span<unsigned char const, 18446744073709551615ul>) + 268 7 WebCore 0x190861c3c WebCore::DocumentLoader::commitData(WebCore::SharedBuffer const&) + 1488 8 WebKit 0x18e07ca3c WebKit::WebLocalFrameLoaderClient::committedLoad(WebCore::DocumentLoader*, WebCore::SharedBuffer const&) + 52 9 WebCore 0x190869db4 WebCore::DocumentLoader::commitLoad(WebCore::SharedBuffer const&) + 228 10 WebCore 0x1909521e4 WebCore::CachedRawResource::notifyClientsDataWasReceived(WebCore::SharedBuffer const&) + 268 I was able to reproduce this in Safari on beta 4 just by opening the following trivial xhtml file from the file system - it does the same thing it does in our app, which is reloads and crashes several times, followed by the "A problem repeatedly occurred with..." error message. <?xml version="1.0" encoding="utf-8"?> <!DOCTYPE html> <html xmlns="http://www.w3.org/1999/xhtml" xmlns:epub="http://www.idpf.org/2007/ops" epub:prefix="vst: http://vitalsource.com/"><head></head><body class="dash" epub:type="chapter" data-begin-o="0" data-begin-o2="0" data-begin-o3="0" data-o="0" id="eid1844" data-end-o="14703" data-end-o2="14703" data-end-o3="14703"><h2 class="title" data-o="0" id="eid1845" data-out="33"><span class="label" data-o="0" id="eid1846"><span class="label-inner"><b data-o="0" id="eid1847">CHAPTER X</b> </span></span>THE SUBMARINE COAL-MINES</h2></body></html> I've also filed a feedback. But posting here just to raise the visibility - this is critical for us. I think it was introduced in beta 4; that's at least when we first noticed it. It was working in the earlier betas, I just don't remember if I tried beta 3 or not. It happens on iOS, macOS, and iPadOS. This has never been a problem in any earlier release of macOS / iOS.
Topic: Safari & Web SubTopic: General
3
1
439
Aug ’25
Xcode 26 - New Swift 6.2 Concurrency Sendable Closure Problems
I'm running into a seemingly unsolvable compile problem with the new Xcode 26 and Swift 6.2. Here's the issue. I've got this code that was working before: NSAnimationContext.runAnimationGroup({(context) -&gt; Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }, completionHandler: { self.endIgnoreFrameChangeEvents() }) It's very simple. The clipView is a scrollView.contentView, and "animated" is a bool, and p is an NSPoint It captures those things, scrolls the clip view (animating if needed) to the point, and then calls a method in self to signal that the animation has completed. I'm getting this error: Call to main actor-isolated instance method 'endIgnoreFrameChangeEvents()' in a synchronous nonisolated context So, I don't understand why so many of my callbacks are getting this error now, when they worked before, but it is easy to solve. There's also an async variation of runAnimationGroup. So let's use that instead: Task { await NSAnimationContext.runAnimationGroup({(context) -&gt; Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }) self.endIgnoreFrameChangeEvents() } So, when I do this, then I get a new error. Now it doesn't like the first enclosure. Which it was perfectly happy with before. Here's the error: Sending value of non-Sendable type '(NSAnimationContext) -&gt; Void' risks causing data races Here are the various overloaded definitions of runAnimationGroup: open class func runAnimationGroup(_ changes: (NSAnimationContext) -&gt; Void, completionHandler: (@Sendable () -&gt; Void)? = nil) @available(macOS 10.7, *) open class func runAnimationGroup(_ changes: (NSAnimationContext) -&gt; Void) async @available(macOS 10.12, *) open class func runAnimationGroup(_ changes: (NSAnimationContext) -&gt; Void) The middle one is the one that I'm trying to use. The closure in this overload isn't marked sendable. But, lets try making it sendable now to appease the compiler, since that seems to be what the error is asking for: Task { await NSAnimationContext.runAnimationGroup({ @Sendable (context) -&gt; Void in context.duration = animated ? 0.5 : 0 clipView.animator().setBoundsOrigin(p) }) self.endIgnoreFrameChangeEvents() } So now I get errors in the closure itself. There are 2 errors, only one of which is easy to get rid of. Call to main actor-isolated instance method 'animator()' in a synchronous nonisolated context Call to main actor-isolated instance method 'setBoundsOrigin' in a synchronous nonisolated context So I can get rid of that first error by capturing clipView.animator() outside of the closure and capturing the animator. But the second error, calling setBoundsOrigin(p) - I can't move that outside of the closure, because that is the thing I am animating! Further, any property you're going to me animating in runAnimationGroup is going to be isolated to the main actor. So now my code looks like this, and I'm stuck with this last error I can't eliminate: let animator = clipView.animator() Task { await NSAnimationContext.runAnimationGroup({ @Sendable (context) -&gt; Void in context.duration = animated ? 0.5 : 0 animator.setBoundsOrigin(p) }) self.endIgnoreFrameChangeEvents() } Call to main actor-isolated instance method 'setBoundsOrigin' in a synchronous nonisolated context There's something that I am not understanding here that has changed about how it is treating closures. This whole thing is running synchronously on the main thread anyway, isn't it? It's being called from a MainActor context in one of my NSViews. I would expect the closure in runAnimationGroup would need to be isolated to the main actor, anyway, since any animatable property is going to be marked MainActor. How do I accomplish what I am trying to do here? One last note: There were some new settings introduced at WWDC that supposedly make this stuff simpler - "Approchable Concurrency". In this example, I didn't have that turned on. Turning it on and setting the default to MainActor does not seem to have solved this problem. (All it does is cause hundreds of new concurrency errors in other parts of my code that weren't there before!) This is the last new error in my code (without those settings), but I can't see any way around this one. It's basically the same error as the others I was getting (in the callback closures), except with those I could eliminate the closures by changing APIs.
5
0
258
Jun ’25
Swift 6 concurrency - Xcode 16b5 - init() is always nonisolated?
I noticed a change from previous betas when I attempted to compile my code with Xcode 16 beta 5. If I have a class that is MainActor isolated, and it overrides init(), it looks like this init is always considered nonisolated now, even for a MainActor isolated class. This was not the case before. For example, I have a class that inherits from NSScroller. It defines a default initializer init() which calls the designated initializer - super.init(frame:CGRect()). This is apparently not allowed right now. If that's the case, how can one even default-initialize a class??? It also doesn't let me initialize other properties, since everything is MainActor isolated. Here's an abbreviated example. class MyCustomScroller : NSScroller { init () { super.init(frame: CGRect()) scrollerStyle = .overlay alphaValue = 0 } } This was allowed in prior betas. However, in beta 5, all 3 lines of my init generates an error such as: Call to main actor-isolated initializer 'init(frame:)' in a synchronous nonisolated context or Main actor-isolated property 'scrollerStyle' can not be mutated from a nonisolated context Is it just no longer possible to default-initialize MainActor classes, such as NSViews, now? The first line is particularly problematic because if I change it to just call super.init() then I get this error instead: Must call a designated initializer of the superclass 'NSScroller' You must call the designated initializer ... oh wait, we won't let you. Too bad.
5
3
2.5k
Aug ’24
UIAccessibility.Notification concurrency errors with Xcode 16 beta 2
I am running into some Swift 6 concurrency errors that I think are due to an odd oversight in the UIAccessibility Swift interface. There are a number of constants defined in here for various things, most of which are marked "let" (appropriately). However, the constants for notifications in extension UIAccessibility.Notification are all marked as var for some reason. For example: public static var pageScrolled: UIAccessibility.Notification Because it is var, not let, anytime I try to access it, I get a concurrency violation. I am baffled as to how I am supposed to work around this. For example, this line of code: UIAccessibility.post(notification: .pageScrolled, argument: "test") gives the error: "Reference to static property 'pageScrolled' is not concurrency-safe because it involves shared mutable state" I can't for the life of me figure out how to work around this. I guess maybe define my own constant somewhere and suss out the rawValue somehow for now? This really needs to be fixed in the SDK.
Topic: UI Frameworks SubTopic: UIKit Tags:
5
0
872
Jul ’24
NSAccessibilityElement sendable but not MainActor?
I'm working on Swift 6 concurrency support for our app. I've always thought of NSAccessibilityElement as being like all of the other UI classes- only used (or usable) on the main thread. As far as I've seen, they are always called on the main thread. But in Xcode 16 beta 2, it's only marked as Sendable but not MainActor. Is that just an oversight or do we need to worry about these being used / called on threads? It's easy enough to do the async work (well, not that easy), but I don't want to do all that work if Xcode 16 beta 3 is just going to add a MainActor to it. I've already been burned by that once, in WebKit- the first beta was missing several MainActor declarations, in places where it was unclear from the documentation. I added a bunch of async fixes to my delegates, only to have to take it all out when the second Xcode beta shipped and the SDK headers changed. How complete are the async declarations in the Xcode 16 SDKs?
1
0
632
Jul ’24
Convert AVSpeechUtterance rate to/from Words Per Minute?
I need to be able to interpret the values in AVSpeechUtterance's rate parameter as words per minute. It looks like it is just an opaque 0.0 - 1.0 value with 0.5 as the default. The old NSSpeechSynthesizer API lets you specify a rate as words-per-minute, but there doesn't appear to be any mapping to the new values. Should I just file a Feedback request for this feature? I'd be fine if there was just some sort of API to return the WPM for a given rate value (or visa-versa), or even just document a multiplier equation I could use to do the mapping. Or maybe it ever varies depending on the voice? If we can't have words-per-minute, even just a way to figure out a multiplier (where 1x is the default speed, 2x is 2 times the default speed, etc) would be helpful. We just want some kind of text label describing the speed, in units that make logical sense to a user, and that can be exposed to accessibility. 0.0 / 0.5 / 1.0 just isn't terribly descriptive.
0
1
566
Feb ’23
UIScrollView Scroll Indicator Request
I'm working with UIScrollView and wishing I had more control over when the scroll indicator is visible. It looks like the scroll indicator's visibility is entirely controlled by the internals of the gesture handlers and there's very little customization available. We can hide the indicators entirely, so they don't show up when the user scrolls, and we can briefly flash them to indicate where they are when a view first appears. But neither of these things covers exactly what I need. My UI has 3 vertical UIScrollViews in a horizontal line. The middle one is actually a WKWebView. On either side of the web view, to the right and to the left of it, are the two UIScrollViews. These scroll views have buttons that are lined up with content in the web view. Whenever the user scrolls in any one of these three views, the other two are scrolled programmatially to match using setContentOffset(animated:false), to give the illusion of one single scroll area spanning the screen. For the most part, this works extremely well. What breaks this illusion is the scroll indicators in each scroll view. Whenever you scroll in a view, the scroll indicator appears to the right of that scroll view, which for the left and middle views appears to be in the middle of the screen. These get very distracting. What I'd really like is for there to be a single scroll indicator in the right-most UIScrollView that is visible whenever I am scrolling any of the three scroll views, and then just always hide the others. I can mostly accomplish this by setting showsVerticalScrollIndicator to false for the middle and left views, and then setting this property to true for the right one. The problem with this is, then I only see the scroll indicator when I am scrolling in the rightmost UIScrollView. I want to be able to programmatically tell the rightmost view to show its scroll indicator whenever I am scrolling in the other two views. The interesting thing is, if the scroll indicator is in the process of either showing, or fading in / out, then scrolling it programmatically does exactly what I want - it does keep the indicator visible and moves it like you'd expect. I just want to be able to programmatically kick it into that state without the user actually interacting with it. Flashing the scroll indicator whenever I programmatically scroll seemed like maybe an option, but it is not the same. It just ends up briefly flashing when I stop scrolling, or when I stop moving the scroller. It's more distracting than helpful. I have the same UI in AppKit using NSScrollViews. NSScrollView actually does exactly what I want, with its overlay scroller appearance. By default, the right view's scroller is hidden. When you scroll it programmatically, it shows the scroll indicator, scrolls it along, and then (after a brief period of not getting calls to move the scroller) it autohides again. This AppKit behavior fits my needs really well. I just want some way to do the same thing with UIScrollView. Building my own custom scroll indicator and drawing it myself is probably an option but that is probably a fair amount of work? Especially trying to match the system behavior exactly. I try to avoid custom UI when possible to avoid breaking with future OS updates.
Topic: UI Frameworks SubTopic: UIKit Tags:
1
0
1k
Nov ’22
Xcode 13 keeps showing line numbers even though I have the preference off
I have "Show line numbers" turned off. But today Xcode 13 started randomly showing line numbers in the left sidebar even though I don't want it to. If I turn the preference to show line numbers on and then back off again, they go away. For a while. They ... keep ... coming ... back. I've tried quitting and relaunching Xcode but it doesn't seem to have helped. Any ideas? Seems like a bug. I may have to start learning to live with them. It seems like it might have started when I used the feature to compare a file with historical versions of it in git. I think it shows line numbers when you're in that view? But I'm not looking at that anymore and they are still randomly reappearing in my code files. (The new GUI for viewing that is much more confusing to find than the old one, too.) Sorry this is a minor thing but it is making me crazy.
3
0
1.8k
Jan ’22