I am thrilled to share some potentially great news - with the upcoming release of macOS Sonoma 14.2, Apple may finally have fixed the longstanding “Safari not responding” bug that causes repeated temporary freezes for many when using VoiceOver on a Mac.
As I outlined in my post in October about why I could no longer recommend Macs to fellow blind computer users, this frustrating bug has been a major pain point for many VoiceOver users on Mac across multiple MacOS versions. For the worst effected, it causes frequent temporary freezes that can result in the user's Mac randomly and sporadically becoming unusable for up to several minutes at a time, dramatically impacting productivity and the overall user experience of macOS and VoiceOver.
However, with the latest macOS update, Apple seems to have possibly resolved this longstanding issue once and for all. Since the second developer beta release in early November, I have not experienced a single “Safari not responding” extended freeze on macOS Sonoma 14.2. This is even when pushing VoiceOver to its limits on complex web pages. Pages that might previously trigger an extended freeze now load without issue. I have encountered occasional brief instances of the “Safari not responding” message, but these have been rare. Typically these brief freeze-ups last no more than a couple seconds before Safari recovers. They likely fall within the normal range one might expect when loading complex webpages. Other testers involved in the beta program have reported similar experiences. Additionally, apple has indicated through a response to my bug report in Feedback Assistant that they believe this bug to be resolved.
Furthermore, this improvement doesn't just apply to Safari - I'm also no longer experiencing any extended “not responding” messages in other WebKit-based applications that used to occasionally freeze. So Apple appears to have potentially addressed the underlying issue across WebKit, not just Safari specifically.
I do want to stress that the prevalence of this issue has been inconsistent across users. Some VoiceOver users report never encountering the “Safari not responding” bug at all. Others experience it occasionally, while for some of us it occurs frequently and is highly disruptive. Additionally, there has never been a consistent way to reproduce the “Safari not responding” behaviour - it will occur randomly and sporadically. The same web page may work fine multiple times before suddenly triggering a freeze. So while the fix seems comprehensive based on my own experience and that of some other testers, it would be hasty and unwise for me to claim that this issue is definitively fixed for all. it's possible some users may still encounter extended freeze ups in certain situations. My own machine is a M1 MacBook Air with 8GB of RAM, for reference. Given the inconsistent nature of this bug in the past, I can't guarantee it is 100% squashed for every configuration and use case. However, as somebody who dealt with regular frustrating occurrences previously, the complete absence of any extended “not responding” messages since updating is very promising and gives me confidence Apple has at least partially addressed the underlying issue. Please do share your experiences after updating - positive or otherwise.
I cannot adequately express how thrilled I am by this development. The relief of no longer having those frustration-inducing system freezes constantly interrupting my work is immense. If the issue does indeed prove to be completely resolved, I would once again feel confident relying on and recommending Macs to fellow blind users thanks to Apple finally addressing this bug.
While I was publicly critical of Apple for letting this drag on so long without a fix, I want to sincerely thank the company for making it an urgent priority to finally and comprehensively resolve the issue. I recognise it likely presents complex technical challenges. But Apple's engineering team is clearly pulling out all stops to permanently squash this bug, and we are extremely grateful as users.
I also want to thank everyone in the blind community who has persistently reported this issue to Apple over the years and provided details on situations that trigger the “Safari not responding” bug. Your bug reports and vocal feedback have been invaluable in keeping pressure on Apple to prioritise fixing this problem. The information you provided likely also helped Apple's engineers isolate the cause of the freeze issues and identify an effective solution. This fix wouldn't have happened without the community repeatedly making their frustrations clear and contributing detailed examples and test cases. Your efforts underscore the importance of speaking up when accessibility issues arise and not silently tolerating them. So thank you all for helping drive this change.
The progress on a “Safari not responding” fix is a reminder of Apple's capabilities when they truly dedicate resources and talent towards an accessibility issue. It restores faith that Apple cares about delivering the best possible experience for its blind and low vision customers, not just sighted ones.
Of course work still remains to address other issues and frustrations in the VoiceOver experience on Mac. But fixing this singular pain point would be a major leap forward in performance and usability. Apple deserves kudos for finally prioritising a fix, and I hope they will work to quickly resolve remaining issues.
I look forward to once again feeling comfortable recommending Macs to fellow blind computer users thanks to Apple squashing one of its most notorious accessibility bugs. It will be a great day for VoiceOver users who will no longer have to face those frustrating "Safari not responding" messages constantly interrupting work and leisure. Thanks Apple for hearing our feedback and making this a priority fix. It is hugely appreciated.
Note: Apple released the release candidate build of macOS Sonoma 14.2 to beta testers this week. While Apple has not officially confirmed the public release date, past experience with macOS betas indicates that the stable public release usually closely follows on the heels of the release candidate build being issued to testers. So users can expect the final version of macOS Sonoma 14.2 to be publicly rolled out next week, barring any last minute issues.
Comments
Optimistic
Fingers crossed.
I am very excited. As I…
I am very excited.
As I wrote in the thread with this problem.
I submitted a report to Apple a while ago.
I received a reply from them that the problem no longer occurs in the beta version.
Since I'm not updating to the beta version, I was waiting for confirmation of this news, or the release of the official version.
I'm still waiting for my impressions after upgrade, but your post makes me feel positive.
Unfortunately I’m on a 2017 iMac, so cannot download macOS Sonom
Hi, unfortunately I’m using a 2017 iMac and cannot download MAC OS Sonoma, but it is good that the not responding bug seems to be fixed.
Safari Betas
Oliver could you please tell how to download Safari betas?
Downloading betas
Hey there, you can download the public beta by going to system settings/general/software update. There is a setting that says MacOS beta updates, and it says off. Find the show more(Or learn more,) and there will be a list of options, one of them being MacOS 14 public beta. Select that, click done, and check for updates. :-)
You can also run the developer beta as well
You can also run the developer beta as well. Just make sure that you are signed in with the same Apple ID, then you should be all set and ready to go. I'm glad that Apple fixed the long-standing Safari is not responding issue. So far I have not had any problems and it has not shown up.
Intel-based macs?
I'm really excited to hear that this issue is resolved. I've stuck primarily to the bootcamp partition on my system for over a year, in large part due to the safari bug.
I had assumed that the issue would not be present on m1 and newer systems running on Apple Silicon, due to the tighter integration between hardware and software. Since Safari does not freeze up on iOS, my logic told me that the difference appeared to be the custom processors in those devices. When apple announced m1, I immediately concluded that voiceover performance would naturally become comparable to the iOS experience. I'm quite surprised to learn that this has not been the case.
Having said that, I'm curious to hear from beta testers running this build on an Intel-based mac. Have you also seen improvement in the responsiveness and reliability of safari? If so, is it to the same impressive degree as described above?
Older versions of macOS
It is also worth noting that MacOS Monterey and Ventura have continued to receive updates to the latest version of safari. The question now becomes whether the problematic code was in Voiceover or Safari. If the bug was in Safari, then Monterey and Ventura users should see the same improvement when they upgrade to Safari 17.2.
However, If the bug was caused by an issue in Voiceover, then it's anyone's guess whether Apple decided to backport that Voiceover fix to the older versions of MacOS. OS updates for prior versions typically only include security fixes, but I could see Apple making an exception in this case. If they don't, i believe we should lobby strongly with Apple to backport this crucial performance fix as well. I believe they will do so if they hear from enough people. This may not be necessary. We'll see what the next few weeks bring.
I'm cautiously optimistic also
I've done everything i can think of to get the dreaded not responding but so far, knock wood, ow! It seems to work. Seriously though, I could usually get it to do that if i just typed the website fast as hell hitting enter. Here's hoping the next tiny little errors get fixed such as not showing all edit fields like on this site. Only time will tell.
Let's hope so
I will definitely appreciate it if I can log into AWS Management Console in Safari next week without having to start up my Windows laptop. So fingers crossed.
But unless they have fixed some of the new bugs brought in with Sonoma, then it won't change how I feel about this update.
Cake
Oliver, I'll chip in on the cake. But I'd like it to read, "Safari Responding!"
Just in Time Too?
In a sense this couldn't've come at a better time, as I registered on the WebKit website and have not done much on there yet. The good news is that I got approved and have written down my password. As I've stated previously I probably haven't experienced SNR as much as others, but it has cropped up on my end from time to time. In addition, it turns out that a sister of mine was forced to update to Sonoma. She is also a VoiceOver user, and I think has run across this issue as well. But she's not as much of a geek-freak as I am, lol. Can I have some of that SNR cake now?
I confirm that although I am still new on Macs
Hello folks,
Hope you're doing well!
I don't usually post unless I find it necessary, and necessary, this certainly is!
I bought an m2 pro base model 14 inch macbook a couple months ago. I was more disappointed than I thought I will be, the ux is far from being as good as it is on ios. You would all agree with that.
I am a casual developer on windows with nvda as my primary screen reader and jaws only when nvda render powerpoints poorly... So your advance geek user.
It was my understanding that this safari does not respond bug and was actually something system wide present and in the very core of voiceover itself. As I upgraded from ventura to Sonoma, this "app does not respond" even ocasionally found his way in status bar (yes), finder, software update popup when displaying the license, google chrome browser and all electron chroeme/chromium (which one is it anyway?) based apps. So I thought that this bug would appear whenever there was a huge amount of element to be parsed through the accessibility API (not talking about elements shown on screen although they might strongly be related), and somehow voiceover would freeze trying to gather them all at once and failing at doing so. And the very place we're likely to have huge element to be parsed (I know that Voiceover doesn't create its own virtual view unlike other windows screen reader so I might be wrong but VO certainly does something so user can navigate in web elements) is web pages, especially modern web apps. I never believed it was a webkit only issue, if that was the case we would have had it on ios too as all webview are forced to have the same webkit backend there. But I am certainly not a working developer, so if big folks think that it's a webkit issue or my statement is false who am I to contradict them?
So!
I upgraded to 14.2 rc yesterday. For me, I had the safari does not respond like the first day of me setting up the mac, on gmail web standard view with 100 rows of messages, on both safari and chrome, intrestingly not or less on edge. Voiceover would constently freeze even with this wierd trackpad heading workaround as well as on many overloaded webpages, but gmail is my case test. I then opened gmail in safari on 14.2, it was litteraly my first action after seeing this thread and upgrading.
Guess what! No problem, like **at all**! I was able to very quickly move between messages on gmail, as well as on heavy pages like facebook/instagram posts with lots of comments. I tried these specific pages because for me the bug would always 101% be triggered there. But after just 30 minutes of testing, which I know is virtually nothing, I can reasonably say that if its not completly over, there is a significant improvement to this. I was hesitating to post this, I don't aim to give us false hopes, but for me it seems to be resolved for my personal use case.
Let me know what you think!
Great news
That's awesome that it's working so well on 14.2. Keep those reports coming in.
Over the months and years, many have suspected a possible correlation between SNR and larger-than-average content. I'd like to express my skepticism.
For a while, I was seeing it every time I followed an AppleVis discussion link then used Command+left bracket to return to the home page. Boom, SNR, every time. And that's simply not a lot of content, maybe a few kbytes. I could immediately turn around and load the NYTimes.com landing page without issue, and that's probably an order of magnitude more content.
It's important to remember that this bug is a web page that has loaded instantly for visual users and only VoiceOver users are blocked. If it were content-size-related, I'd expect visual users to be blocked as well.
You know what would be really nice? If Apple got back with us and explained the root cause of this issue and what was done to resolve it. Without that information, all we can do is cross our fingers and hope it never recurs.
This bug is wierd anyway
Hi,
I know that too, it's purely a voiceover bug. I have a Mac for just 3-4 months. From what I read here and there this bug as as much paterns as there are blind users with mac and voiceover. I think the issue is maybe with webkit but with memory/information management and how elements are parsed and rendered in the backend of the accessibility APIs. But I am everything but a developer, not to mention knowledgable enough to talk about this. :) But I have this does not respond bug constently on safari as well as on chrome so I am skeptical (feeling wise, not objective opinion at all) of it being a WebKit bug.
Re: SNR
@Ekaj +1.
web tables
have they also fixed the vo bug wher if a table has other web elements like links, it jumps out and you have to navigate into it again?
Sometimes you aren't even able to get in using vo left / right or table commands to go up / down rows / columns.
Cursor actions available issue
Does any one faces the issue in Sonoma 14.2? When ever you use caps lock key as your VO key, landing on any edit field triggers a message, Cursor actions are available press caps lock plus J to jump. I contacted the apple accessibility team regarding the issue and they said this is a known bug. This issue makes typing very difficult and in some cases impossible.
I haven't experienced this…
I haven't experienced this bug personally, but I heard one report that it is resolved in macOS Sonoma 14.2. However, this is a single anecdote that I am aware of, so I can't confirm whether the bug is truly resolved or not.
Reply: I haven't experienced this…
I pray that this issue gets resolved in the 14.2 update. This bug makes typing in the edit fields a nightmare.