How to avoid Safari crashes: Option-click on large media files
Posted by Pierre Igot in: MacintoshJanuary 5th, 2007 • 10:34 am
I just can’t help it: When I encounter a link to a web page that I might be interested in reading, instead of clicking on the link, switching to Safari, waiting for the web page to load, reading it, and then closing the window, I usually click on the link and then either keep on reading the page with the link that I am currently reading, or switch to something else entirely. And this happens again and again.
The end result is that I always have tons of different web pages loaded in various Safari windows and tabs at any given time. Sometimes this goes on for days, I get caught up in other stuff, and I end up having web pages that I loaded in a Safari window or tab several days ago and still have not read and still want to read some time.
All this makes Safari crashes particularly painful. When Safari crashes, all the numerous web pages loaded in various Safari windows and tabs are gone, and they have to be painstakingly reloaded one by one after relaunching Safari, by exploring your “history” of the past few days and locating in that mess of URLs the pages that you actually want to reload.
There are, fortunately, ways to alleviate such a problem. But they involve using a third-party hack such as SafariStand. With SafariStand, at any point while Safari is running, you can create what it calls a “shelf” based on the current “workspace,” which simply means that you are recording all the URLs to all the pages that are currently loaded in Safari in a “shelf” that you’ll be able to refer to later on (after a crash, for example) if you need to restore that “workspace.”
It works reasonably well (in spite of the rather user-hostile terminology), but it’s a third-party hack. And you still have to remember to manually create a “shelf” regularly, in order to make sure that you have an up-to-date record of all the pages that are currently loaded in Safari. (More recent versions of SafariStand appear to make an attempt to remember your currently open pages in the event of a crash even if you haven’t manually created a shelf. But I am not sure exactly how this works, and how reliable it is.)
All this is to say that, even with a third-party hack such as SafariStand, Safari crashes still suck. So the best thing is still to try and avoid them altogether. Unfortunately, over the years the technologies used to design web pages and the browsers themselves have become so complex that crash prevention is way beyond the control of the end user.
But there are still things you can do to try and reduce the incidence of crashes.
In my own experience, especially since getting broadband access to the Internet (sort of), there is one specific aspect of web browsing that seems to substantially increase the frequency of Safari crashes. And it involves large media files.
Before I had broaband, I would simply avoid such files altogether, so I didn’t really suffer much from crashes caused by large media files. But now that I have broadband (sort of), I tend to load such large files more often—and the frequency of Safari crashes seems to have increased accordingly.
By “media file,” I mean any kind of large file such as a music file (MP3, AAC, etc.), video file (MPEG, MOV, etc.), or even a large PDF document. By default, Safari attempts to load such files within the current web page. If you click on a link to an MP3 file, for example, Safari displays a blank web page with a QuickTime logo in the middle of the page, and then starts loading the MP3 file and starts playing it as soon as it thinks it has buffered enough of the file. The same thing happens with video files. With PDF files, the web page becomes a PDF viewer similar to the separate Preview application, but with far fewer controls. (If you own the Adobe Creative Suite package, which includes Acrobat Professional, it will also attempt to install its own PDF plug-in to view PDF files within web pages. But that plug-in is even worse than Mac OS X’s built-in plug-in. It’s OK when it works, but when it doesn’t, you get yet more freezes and crashes in the browser.)
In my experience, this kind of behaviour (loading a large media file within a Safari window) is a significant factor in the instability of the application as a whole. I don’t know why this is. I suspect it has something to do with network responsiveness. Safari starts loading the large media file within a window, and then it expects it to load at a certain rate. If, for any reason, the server at the other end is not as responsive as Safari expects, then you start getting the spinning beachball, and then, often enough, the application just freezes or crashes.
Since there is no way for you, the end user, to control the responsiveness of remote servers, you are pretty much powerless. All you can do is watch as Safari seizes up and becomes unresponsive and then freezes or crashes.
But there is one strategy that avoids the problem altogether and seems to help reduce the incidence of browser freezes and crashes. Instead of loading large media files within your browser window, you can force the browser to download the media files in its download queue, without even attempting to display/play them within a browser window. The shortcut to do this is to option-click on the link to the media file instead of simply clicking on it.
This will effectively force the browser to treat the media files as files that it is unable to rend/play/display itself and to simply download them to your preferred destination for downloads (which is by default the desktop, but can be changed in your browser’s preferences). Once the files have been downloaded, the browser won’t do anything with them. It will be up to you to navigate to the downloads destination in the Finder and to open the downloaded files with your preferred application. PDF files can be opened with Preview. Music and video files can be opened with QuickTime Player.
If there is any problem with the file you are trying to open, it will only cause Preview or QuickTime Player to crash—not your web browser with all the web pages currently loaded in various windows and tabs.
Of course, opening the media files with another application is not as convenient as viewing/playing them within the browser—but in my experience it greatly helps reduce the incidence of browser crashes, and so you have to weigh the inconvenience of having to view/play the media files separately versus having to deal with browser crashes.
In addition, when you load media files within the browser window, it is not always easy to keep those files, should you desire to do so. When you download the media files separately, on the other hand, they are automatically saved in a readily accessible destination on your hard drive, and you can decide whether to keep them or trash them yourself once you have viewed/played them.
Of course, this option-click shortcut is not a solution for large media files that are embedded within web pages and not accessible through a standard hypertext link. For example, YouTube videos cannot be easily downloaded this way.
For such embedded files, you have no choice but to view/play them within the browser, with the associated risks in terms of browser stability—although in my experience YouTube videos are not particularly problematic. (I’ve recently written a blog post about how to save, play, and convert YouTube videos in Mac OS X, however.)
But in many cases, large media files are indeed accessible through a hypertext link/URL, and you can avoid loading them within a browser window by using option-click.
Finally, if all you have is the actual direct URL to the media file, and not a hyperlink on a web page that links to the file and that you can option-click on, you can also use the following trick: paste the URL in the address bar in your browser, and then type option-Return or option-Enter on your keyboard, instead of just Return or Enter. Again, instead of loading the media file in the browser window, this will force the browser to load the media file as a separate file in its download queue, and you will again avoid the stability problems associated with loading large media files within a browser window.
January 5th, 2007 at Jan 05, 07 | 11:52 am
You should try using OmniWeb for saving browsing windows. I browse the web the same way as you(even though I have a broadband connection): As I read a webpage, I command click on any link that interests me, which opens up a background tab (or window- it can be specified in the preferences), and then keep reading. I’ve had tens of windows with tens of tabs open, all which I want to read eventually. But, if OW crashes, or even if I accidently quit it (which I’ve been known to do), all I have to do is relaunch OW, and all of the pages I had open are reopened. This is all done in the background, as long as the workspace has “Auto-save while browsing” checked in the workspace window. Workspaces also allow me to close a bunch of windows but keep them saved so that I can clear my screen. This is nice if I’m doing development work, and I have a bunch of API documents open- then I go to work, switch workspaces to my daily read, and then I am set.
OW is also faster and more compatible than Safari, as it uses a newer build of WebKit. There is also a ton of other features than OmniWeb has that Safari doesn’t, such as per-site preferences, per-site ad blocking, etc. You should check it out.
January 5th, 2007 at Jan 05, 07 | 1:59 pm
SafariStand pretty much does the same job as the feature you describe.
My main issue is with browser stability. I don’t know how much better (or worse) OmniWeb fares in that department. If it relies on the same plug-ins, then it probably has the same problems. I would still use option-click and option-Return to download large media files separately instead of viewing them within the browser.
The problem with any manual save or auto-save feature for web pages is that, in the event of a crash, you still have to reload everything. And in my experience, even with a semi-broadband connection such as my satellite hook-up, if the number of pages to be loaded simultaneously is too large, you still have to deal with half-loaded pages, loading failures, etc. So I would still want to avoid crashes and freezes as much as possible, in order to avoid having to deal with such hassles.
That said, I am regularly checking other browsers. I occasionally use Camino, for example. I would have a hard time convincing myself that I need to pay for a browser, though, even if the fee is relatively small.
January 8th, 2007 at Jan 08, 07 | 5:12 am
For a measly US$12, you can get the crash protection power of Saft, which has a superior crash protection mechanism. Not only does it store every window and tab you have open, save all of this at quitting time, and restore it all when you reopen Safari, if Safari crashes, it pops up a dialog box that lets you uncheck the tabs you don’t want loading again. So if one particular web page gives you problems over and over, you can simply uncheck it and it won’t load.
Plus Saft has tons of other features that greatly enhance my Safari browsing experience. I could go on and on about it and sound like a marketing drone, but it’s really that good.
January 11th, 2007 at Jan 11, 07 | 12:59 am
I wonder about your QuickTime configuration; do you perhaps have a buggy QuickTime component that makes it crash when dealing with certain types of media? I never have Safari crash on me when handling media files, and I’ve been known to play multi-gigabyte DV files through it (from the server upstairs, admittedly).
I’ve also done things like command-clicking multiple media files to open them each in tabs, and Safari seems to handle that with aplomb.
If you run across any reproducible Safari-crashing sites/files, I’d be interested in comparing notes.
(Tangentially: I’m not a fan of Safari’s PDF handling (too minimal), and I hate Adobe’s plugin (too bloated), but the schubert|it PDF Browser plugin is fabulous. If only they would get an Intel binary out the door.)
January 11th, 2007 at Jan 11, 07 | 10:41 am
The QuickTime components I have are the following:
AppleHDVCodec.component
AppleIntermediateCodec.component
DesktopVideoOut.component
DivX Decoder.component
DivX Encoder.component
DVCPROHDCodec.component
DVCPROHDMuxer.component
DVCPROHDVideoDigitizer.component
DVCPROHDVideoOutput.component
DVCPROHDVideoOutputClock.component
DVCPROHDVideoOutputCodec.component
FCP Uncompressed 422.component
Flip4Mac WMV Export.component
Flip4Mac WMV Import.component
IMXCodec.component
LiveType.component
Motion.component
Perian.component
But I haven’t noticed any pattern about the type of media files… I really think it’s more of an issue with server responsiveness. If Safari doesn’t get a fast-enough response from the server (and with my satellite connection, this can happen quite often), then it just locks up or crashes.
That’s my theory, anyway.
Unfortunately, it’s not really reproducible. Most of the time, if I try again after relaunching Safari, it works fine.
And I only occasionally get a crash report. Most of the time, Safari either freezes (= no crash report after force-quit) or crashes without generating a crash report.
As for PDF files, I’ll continue to download them as files and view them in Preview. I much prefer this approach.
January 11th, 2007 at Jan 11, 07 | 2:43 pm
Dan, in case you’re interested, I’ve just had a crash when trying to load a YouTube video. This time I got the crash report dialog, saying “Safari has unexpectedly quit.” Interestingly, Safari was still open and frozen, even after the dialog appeared. So it looks like it crashed, then froze before being able to complete the crashing part :-).
Anyway, here’s the crash log, in case you want to have a look. Of course, I suppose it could all be related to my use of SafariStand (which prevents embedded stuff from loading automatically; you have to click on it to start loading it–and that’s when Safari crashes in that case).
Safari-Crash-2007-01-11.txt
January 11th, 2007 at Jan 11, 07 | 2:46 pm
Correction: It was actually a DailyMotion video, not YouTube.
January 12th, 2007 at Jan 12, 07 | 2:48 am
Nothing leaps out at me in the crash report. The crash was in the main thread, DailyMotion rules out QuickTime as the cause, though, as that’s a Flash-based site.
If it’s annoying you enough to invest the troubleshooting effort, I’d start by turning off APE (I see at least Audio Hijack) and any third-party InputManagers you have installed (SIMBL, which is used by SafariStand), and give it a couple days. If Safari is crash-free then, add things one by one until you find the culprit.
(I won’t tell you to remove Spell Catcher X. I know you can’t live without it :-)
If disabling those items doesn’t do it, I’d also look at Default Folder X, since it’s patching the Carbon & Cocoa frameworks in memory, much like APE.
January 12th, 2007 at Jan 12, 07 | 3:50 am
Unrelated to the Safari problem, you can safely remove the DivX Decoder QuickTime component if you have Perian. Perian’s playback of DivX files is as robust as DivX’s, and a bit more responsive (better time from opening to the start of playback).
Their wiki has a list of Codecs Obsoleted by Perian.
January 14th, 2007 at Jan 14, 07 | 12:00 pm
Dan: Yes, I suppose I’ll have to eliminate APE and SIMBL as possible culprits, although eliminating the latter would strip Safari of important functionality for me… As you said, eliminating Spell Catcher X would be much more challenging for me :). Same thing for DFX, really.
Instead, I think I am definitely going to give OmniWeb a try in the next couple of weeks.
As for DivX and Perian, thanks for the pointer. It’s not something that I use very often, but I’ll trash the DivX decoder just the same.