Could Apple Have Finally Squashed the Longstanding “Safari Not Responding” macOS Bug?

Fingers crossed.

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.

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.

Oliver could you please tell how to download Safari 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. 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.

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?

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'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.

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.

Oliver, I'll chip in on the cake. But I'd like it to read, "Safari Responding!"

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?

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!

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.

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.

@Ekaj +1.

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.

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 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.

I pray that this issue gets resolved in the 14.2 update. This bug makes typing in the edit fields a nightmare.