



If you try access any other tab in the menu bar -- like Mac, iPhone, Download, etc. -- they all seem to work. Michael M Cohen at Apple Discussions suggested disabling JavaScript in Safari's preferences under the Security tab. I tried it and it seems to work, but a person really need JavaScript enabled for functions on other sites.
UPDATE: After troubleshooting my MacBook Pro, I isolated the problem to my User Library. From there I found out that by deleting my login items preferences, it cleared the issue up. I started adding my startup items back and found I could recreate the crash when I added LazyMouse and Keyboard Maestro back. Both of these apps rely on having Assistive Devices enable in the Universal Access preference pane. So I went and turned off Assistive Devices, and guess what? No more crashes!
Here is what LazyMouse's developer had to say about the problem; "I've been testing this and have verified that it's not a bug with LazyMouse but rather with Safari 4.0 final and accessibility. To verify this, try turning off LazyMouse but turning on VoiceOver in the Universal Access preference pane. You should get the same crash.
"I'll be filing a report with Apple over this, but in the meantime you can avoid this problem by temporarily turning off javascript in Safari or by adding Safari to LazyMouse's list of ignored apps.
"Although this isn't my responsibility, I'm sorry that you are experiencing this bug."
Ken
ADDITIONAL UPDATE: From Evan Gross, Spell Catcher X's Developer
Generally speaking, when a crash is reproducible (like this one is), (we) developers can figure out where the problem lies fairly quickly. It is a bug in WebKit's accessibility support.
Trivial to reproduce it without the involvement of any non-Apple software:
• Turn on VoiceOver (System Preferences, Universal Access).
• Visit the Apple Store in Safari 4.
Kaboom.
It doesn't really matter whether Enable access for assistive devices is selected, as some apps (like VoiceOver) are trusted accessibility clients, and access is always allowed. Most 3rd party apps are not trusted. So if this bug is kicking in due to a non-trusted app's use of an accessibility API, turning off access will probably stop the crash -- at the expense of that app's functionality.
Anyway, the bug has been fixed in recent WebKit nightly builds. I'm pretty sure that this bug was the culprit. Proof positive that it's not any 3rd party developer's fault, and that no amount of fiddling with prefs files, plug-ins, caches, login items and the like will solve the problem.
My guess is that Apple will push out an update to fix this sooner than later. After all, they take accessibility very seriously, as well as selling stuff at their online store.
FYI: My product uses accessibility APIs, and I was alerted to (but not immediately blamed for) the problem by customers. I discovered all the above when doing my own testing/researching to see what was going on.
ADDITIONAL UPDATE:
The new Safari 4.0.2 update seems to have solved the problem.



