I can no longer get online PDFs to open in a Safari window without this dialog box being displayed:

"Adobe PDF reader cannot find a compatible Adobe Acrobat or Adobe reader to view this PDF. Please select one."

In the Applications list displayed, Preview is grayed out, so not available to select. And Safari won't "remember" that I chose Adobe Reader, presenting the same dialogue box every time.

I wonder if the problem is that I've set Preview as my default app for opening PDFs. Or is it "Safari" which I must select?

OSX 10.5.8
Safari 4.0.3 (with Saft)
Adobe Reader 9.1.2

Join the club. I suggest you go to Reader> preferences>Internet and uncheck "display PDF in browser using". Then log out-log in. Download PDF browser plugin at www.schubert-it.com/pluginpdf/ and install.
You now should be able to see pdf files within the browser. It is not as good as Reader (the scrolling does not work) but it allows to see, magnify, save and print the file.
Hope it helps.

Thanks. "Display PDF in browser using…" is grayed out, so I can't uncheck it. I went through all the other preferences but didn't find one that seemed relevant.

HOWEVER, I did install the plugin you recommended. Now PDFs are displaying in Safari -- way faster than before, and with a black background.

Looks good so far. Thanks for your help.

I hadn't yet quit Safari when I wrote the previous post. On re-loading Safari and clicking on a PDF link, I still get the message asking which app to use. I don't know how to get Adobe to be the default. (And I still prefer Preview for downloaded PDFs.)

when you get the message about which app to choose, you can change it (towards the bottom of the window) from "Recommended Apps" to "All Apps" which should give you access to Preview. then select the button to "always use this". (or some such language).

none of this, of course, explains why Safari stopped showing pdfs in the first place, but it might get you back on track.

Try using Cocktail, OnyX, or TinkerTool System to reset/rebuild the Launch Services Database. Then try resetting your default apps again.

Is it grayed out AND checked? I think it can only be grayed out when unchecked.
Concerning the opening of PDF, I always first see it in the browser then save to desktop. There you can click on any file, then hit command-I (get info) or go there with a right click or control-click and change open with to Preview and then apply to all. This way all pdf files on the hard drive will be openable with Preview. I personally recommend Adobe Reader though for better functionality. Safari has an option of opening downloaded safe files like pdfs. Most people recommend to uncheck it but you might like to check it and see how it goes. Also try Roger's advice - it looks like a pretty sound one to me.
P.S. I have a sneaking suspicion that Joe is right too.

Thanks, all. I'm going to track this over the next week, or so. It's inconsistent whether Safari 'remembers' Reader, or not.

Because of these sorts of glitches in the past, I got into the habit of first downloading the file instead of viewing it in the browser. It's usually been way faster that way. (I tire of watching the spinning rosette in the browser window, i.e. "Is anything really happening?") But sometimes you don't know you're about to click on a PDF file without first looking at the Status Bar.

I downloaded the trial Cocktail and rebuilt Launch Services. The same dialogue came up when clicking on an online PDF. Will see how this goes over the next few days.

So far it seems that Safari only "remembers" Adobe Reader until Safari is quit. When I open Safari again, the same irritating dialogue box is back, asking me to choose an application when I click on a PDF on a web page.

In answer to a previous query: Yes, in Reader's preferences, "Display PDF in browser using…" IS checked, and IS grayed out, so I can't uncheck it.

perhaps it's time to try this from another User Account on your mac. if you don't have another USer account, you can make one (it's good to have for testing things just such as this!) in your Account preferences in the System Preferences.

once your in the other account, open Safari, and find a pdf to open. see what happens!

Thanks. I've just tried that, with no change in results.

Reader is free. Why don't you trash it with preferences (or just preferences) and either launch again (the latter case) or reinstall. Something is wrong. Please tell us how it goes.
Another thought: does it also happen on other browsers? For me, there is no real reason to stick to Safari only.

> if you don't have another USer account, you can make one (it's good to have for testing things just such as this!) in your Account preferences in the System Preferences.

We always recommend that posters creating test user accounts check the "Allow user to administer this computer" box, roger.

You may always make that recommendation; I don't.

What's your reasoning?

Narrowing the scope of the problem of course

After trying "quick fixes", generally the second step is to gather information about a problem. One good thing to know is the general scope of the problem. Knowing if a problem affects just a single user or affects all users generally divides the root of the problem down to user account files (cache etc) or system problems. In most cases, a fix for one does not work for the other, so you can cut your problem solving roughly in half without any additional information.

And it's always a good idea to have a second "emergency" admin account available in case your main account develops a problem that prevents you from logging in.

Of course there is a third group of problem space, hardware vs software, but that is most easily tested by booting the suspect machine's hard drive off another mac, but not everyone has another mac they can use for this. "Hardware, System, User" make up the three primary problem spaces.

And for the record of course, that fourth problem space lovingly referred to as "pebkac". Failing to consider that one can waste a lot of your time.

I think that dk meant that the test account should be a standard account rather than administrator (artie specified administrator). I'd like to see your take on this as well as artie's and dk's. My thought is that an administrator account gives you easy access to all applications so it should be simpler to see if the problem is account-specific.

Other thoughts please?

No, what I really meant is that in the absence of a specific reason to make it an administrator account, why should one do that?

I understand that having a second administrator account is a good idea in general, but why is it a good idea for troubleshooting? What if the user normally runs a standard account? Wouldn't it make more sense to test for account-specific vs. system-wide symptoms in that case by logging into another standard account?

Even with the Adobe Reader 9.1.3 updater installed, results are the same. For now, I can easily live with choosing Reader once a day, assuming I don't quit Safari.

It turns out that Firefox does remember Reader, even after I quit and restart Firefox.

Part of the problem may be that neither Reader nor the Schubert PDF plugin are listed as compatible with Leopard.

Did you get the right versions? According to this, PDF Browser Plugin 2.3.1 is compatible with Leopard (and I have it, in fact) and so is Adobe Reader 9.1.3, which I also have. I'm using AR because the lack of ability to use the mouse's scroll wheel with PDF Browser Plugin is a deal-breaker for me. AR is working fine for me.

> No, what I really meant is that in the absence of a specific reason to make it an administrator account, why should one do that?

I understand that having a second administrator account is a good idea in general, but why is it a good idea for troubleshooting?

Truth be told, I can't think of any particular troubleshooting benefit(s) to be gained by giving one's test account Admin status.

My reasoning (which is akin to V1's "And it's always a good idea to have a second "emergency" admin account available in case your main account develops a problem that prevents you from logging in.") is that there are times when something that requires authentication needs to be done right now, no time for head-scratching or waiting for responses to a post, and having a test account with Admin status kills two birds with one stone in such instances.

> What if the user normally runs a standard account? Wouldn't it make more sense to test for account-specific vs. system-wide symptoms in that case by logging into another standard account?

Interesting thought; perhaps a user who normally runs a Standard account ought to have two test accounts, one Admin and one Standard.

But which troubleshooting aspect(s) of the test account do you envision as being compromised or lost when it is Admin and the account with the issue(s) is Standard?

Well, suppose the problem is a permissions issue: the user is trying to do something for which a standard account doesn't have access. Trying to do the same thing in a test administrator account will yield no problem. Hence, the user—following the black and white reasoning so often employed here—will conclude that there's something wrong with his or her regular (standard) account, and trash a bunch of plists or cache files—as per our frequent urging—and, ultimately (since those approaches won't work), create a new user or reinstall the OS.

Logging into a test standard account, OTOH, would reveal that the problem is not unique to the regular account.

Trying to follow this discussion...
Your last sentence throws me off. Perhaps changing "would" to "could" would ring true more often.(?) At first, I thought the word "not" should be deleted, and it could be if "would" was "could", couldn't it?

That's not a wise crack. I'm serious, about all of it.

I almost forgot about this line of discussion what with its being buried in the middle of a PDF thread.

> Well, suppose the problem is a permissions issue: the user is trying to do something for which a standard account doesn't have access. Trying to do the same thing in a test administrator account will yield no problem. Hence, the user—following the black and white reasoning so often employed here—will conclude that there's something wrong with his or her regular (standard) account, and trash a bunch of plists or cache files—as per our frequent urging—and, ultimately (since those approaches won't work), create a new user or reinstall the OS.

Logging into a test standard account, OTOH, would reveal that the problem is not unique to the regular account.

1. By that reasoning, when your hypothetical user logs in to a standard test account and runs into the same permissions problem se will conclude that se's got a systemic issue and just skip the plist and cache trashing and the creation of a new user and immediately reinstall OS X. (Your user is pretty narrowly focused, having as much troubleshooting knowledge as you give hir credit for while at the same time being unaware that a permissions issue has nothing to do with either plists or caches.)

2. Your scenario has actually established a troubleshooting purpose for creating one's test account as Admin... It can be used to establish that logging in to an account with elevated privileges overcomes a permissions issue in a standard account.