In a previous article, I wrote about the fact that with Microsoft SharePoint 2010, the default behaviour for handling PDF files is to prompt for download instead of opening them directly in the browser. In it, I mentioned how to change this behaviour, both at the application level, and where necessary at the library level.
I recently ran into a case where neither approach fixed the problem. SharePoint continued to prompt for download even though the BrowserFileHandling property was set to permissive at both the application and at the library level. I registered a support call with Microsoft and was told that they’ve seen this, and were working on it, and there was no expected date for an answer.
I decided to do some further experimenting, and found that I was actually running into two different things that caused this. The environment had both, so it made troubleshooting a real treat.
1. Adding the PDF icon to the front end server causes prompting for download
It’s been standard procedure since SharePoint 2007 to manually add in the PDF icon to display PDF documents, as described here. Every time that I do so, SharePoint starts prompting for download instead of opening in the browser. I as yet have no idea why,but it’s repeatable. UPDATE – This has been solved – see below.
2. Creating a site from a custom site template causes prompting for download
With the PDF icon uninstalled,the browser behaviour is correct on all sites in the site collection. If you then create a site template from an existing site with a library, and then use that template to create a new site, you will experience the prompting behaviour on any documents saved to that library. This is NOT true for any new libraries created in the site. You can also run the PowerShell script that I previously posted to reset the properties of the libraries, and they will behave properly.
For the record, the environment that I was working on this problem with was Search Server Express 2010, which is essentially the same as SharePoint Foundation plus the Search features from SharePoint Server.
Both of these problems are quite annoying, and I suspect I’ll be updating this post as I learn more, or as I hear back from Microsoft.
UPDATE
I’ve put together a solution that can be installed on a farm and activated at the site collection level. It’s essentially an event receiver that fires whenever a new web (subsite) is created and it sets all of the lists to Permissive. It works fine for me, and for at least one customer, and I provide it to you here with no warranties express or implied…. If anyone is interested in the code, let me know, but it’s only about 5 lines.
UPDATE – OCT 15 2010
The pdf icon problem has been solved. I’ve been back and forth with Microsoft on this and we wound up exchanging DOCICON.XML files. They sent me back one that worked, and the suggestion was that I change the icon file name to pdf16.gif to accommodate it. However, I noticed that there was an additional attribute in their file, OpenControl=””. I added that to the Mapping tag for my PDF extension, did an IISReset, and the problem was solved. For the record, the complete tag will look like:
<Mapping Key=”pdf” Value=”pdf16.gif” OpenControl=””/>
With pdf16.gif being whatever the name of your pdf icon file is.
Microsoft also confirmed the problem with the custom site templates that I created the solution for above. It’ll have to do until a fix is available.
UPDATE – JAN 3 2011
Reader Christoffer von Sabsay has notified me that this bug has been fixed in the December 2010 Cumulative Update Pack for SharePoint Foundation. For a list of the fixes in this CU, and to request them, go to http://support.microsoft.com/kb/2459108. My event receiver workaround should NOT be required after applying this and you should remove it upon doing so.
[…] I’ve run into more situations where this doesn’t solve the problem. I created a new post describing them here. […]
Thank you! Adding OpenControl=””/> to the end of my tag worked. I had previously configured the pdf icon in DOCICON but M$s KB doesn””t include this tag so I was missing the OpenControl.
I””ve managed to install the wsp file, however when I try to activate it, the activate button from the dialog box is greyed out. I am logged in as administrator, and I am able to activate and deactivate other solutions – any ideas?
That””s very odd – I””ve never seen that behaviour before. Have you tried retracting and redeploying it? Deploying it to a different web app? What authentication model are you using?
Hi,
Regarding your article titled “Adding PDF Icon or Creating a Site From Template triggers Prompt for Download In SharePoint 2010″.
Actually I have the same problem, with the site that i created from the site template, my pdf doc in the library can””t open directly.
You have a solution to fix this so can I get the source code of your solution ?
Thanks n regards,
Rusdi
Yes – you””ll find the link under my first UPDATE section above.
Cheers
Thanks a lot, this really helped med A LOT!!! This is a really anoying bug. Hopes MS fixes this soon. Thanks again for sharing this.
Thanks for this post! OpenControl=”” works for me!
We have exactly the same problem. Unfortunately, we are very much dependent on the possibility to create sites based on custom site templates.
Did Microsoft confirm this issue as a bug? Any feedback on when it might be fixed?
We will try your event receiver approach as a temporary fix. Thanks a lot for the solution!
This bug is now fixed with december CU. Thanks for the workaround!
Thanks Christoffer – I hadn””t been watching the CUs. I””ll update the post accordingly. Cheers.
We eare experiencing the same issue. I have set BrowserFileHandling property to permissive – did not solve the issue. I added the pdf icon to the DOCICON.xml file – did not solve the issue. In installed the December cumulative update- did not solve the issue.
What I did identify is that I can open .pdf files when they are checked out but if the file is checked in, Sharepoint prompts to save the file.
Any suggestions around this?
Same issue here…setting the property to permissive did not solve the issue…it is definitely an IE8 issue…all is well in Firefox. And I also see if the doc is checked in, it needs to be opened, check out it opens in the browser. Workaround is to set up an HTML column, copy the URL, name the doc and it opens in the browser. But doing this is a 2 step process and will not be appreciated by a typical end user…need to automate via workflow performed upon creation.
This seems so counter-intuitive to the basic principle of SharePoint…share not save!
It””s a permission-ing issue: If your users have the ability to edit the documents, SharePoint requires the document be saved. Set the permissions to Read only and the docs open up in the browser.
George – Deb is right. What you””re seeing is SharePoint assuming that you want to edit the PDF files. However, there are two other settings that you may wish to check. Both are in the Library settings for the library in question. The first is under advanced settings, and controls how the file should be opened – in the client application, or in the browser. You””ll want to set the library to open in the browser.
Secondly, you want to check the versioning settings – you want to require documents to be checked out before they can be edited. Do either of these help?
Yep, and if the document is left checked out (which is the condition a multiple doc upload is left in unless you go in and check in all), the end users, regardless of their permission level, will only be able to view the doc (my issue…once I checked the docs in,. the complaints started). My work around is to use an HTML column. Problem is, this is a manual cure, I need to automate via a work flow (I can use Designer to automate the URL, but how do I automate the actual wording I want seen over the hyperlink!)
Deb – Have you tried turning off the require check out to edit option? Is that even an option for you?
I could try that for this instance…thanks. I””ll let you know what I see.
John – I have tried all the settings “Open in Browser”, “Open in client application”, “Check Out before Edit” etc. None seem to make a difference. Even adding a URL column doesn”t make a difference. What I did notice was that when the pdf file does open, it opens in Acrobat reader and not in the browser, even though I have the “Open in Browser” setting on and Acrobat preferences is set to “Open in Browser”. I am not sure why this happens.
The permission issue does make sense but if that is the case, the implementation suck because the default behavior for pdf files would be to open for view and not for edit. The same happens with .html files. Even stranger – I have a page with page viewer web part. If I point the page viewer to an html page, I get a popup to save the file.
Hi:
There is a better way to handle “Browser File Handle” issue. Take a look at my blog here: http://www.pdfsharepoint.com/sharepoint-2010-and-pdf-integration-series-part-1/
Solution #2 addresses Pdf extension without exposing entire Web Application to “Permissive” browsing. Setting “Browsing File Handle” to “permissive” opens too many vulnerabilities with other file extensions.
Thanks,
Dmitry