1, we really need a way to disable previews of attachments like .doc only, not everything (or a alternative).

+1

Our HR department started publishing orga charts in a specific Confluence space. Now users miss a search feature within the preview of PDF documents.

"Similar as @ShelleyDee, I was also confused with the navigation of the new viewer. The arrows < and > open the next document, while I expected it to turn to the next page (I was viewing a powerpoint slideset). 
It took me some time to find out that I have to use the scrollbar to get to the next page. In case of a powerpoint, this is unusual. 
I think therefore, that the < and > arrows are more confusing than helpful."

+ one for this. All the users complaining this to be confusing UX

Duplicate: CONFCLOUD-45382

@Adam:
Since 5.10 a bunch of new issue tickets were opened and thousands of users are affected (see the comments with customers with 4.000 users, we have 500+ users etc.) by a big design error - the new preview introduced a really big usability issue - or a bug. Just declaring it as "not soo bad" and "maybe in a year or more we could think about..." is a punch into the face of each paying customer.

So: What has to happen that Atlassian will fix this big and in several tickets and user complaints covered usability issue - which will cause big pain for Confluence users each single working day?

I had some success as far as I can investigate for the moment.
On our QA system I did the following:

In the General Configuration in "Look and Feel" in "Custom HTML" in the area "At end of the HEAD" I added a view lines of JavaScript code (jQuery):

<script type="text/javascript">
AJS.toInit(function() {
jQuery("a").removeAttr("data-linked-resource-type");
});
</script>

After that the file link is offering open in application / download, no more preview.

Clicking on an image the preview is showing the large version of the image like before.

Reason: Images are not linked by an anchor tag around. jQuery does only impact the a Tag, not the img Tag. So here the preview works.

I  tested a bit around with such a file download link.

Using the Confluence 5.10 default the HTML code in the page is like this:

<a href="/download/attachments/24281097/test.pptx?version=1&amp;modificationDate=1504962236837&amp;api=v2" data-linked-resource-id="24281098" data-linked-resource-version="1" data-linked-resource-type="attachment" data-linked-resource-default-alias="test.pptx" data-nice-type="PowerPoint Presentation" data-linked-resource-content-type="application/vnd.openxmlformats-officedocument.presentationml.presentation" data-linked-resource-container-id="24281097" data-linked-resource-container-version="5">test.pptx</a>

The click on that link is opening the preview of that file. I want to check out how to eliminate that behaviour.

I created a user macro with exact this code and the behaviour is exact like before (as expected).

I started to take out some of the attributes and found out, that the following attribute seems to be responsible for the preview:

data-linked-resource-type="attachment" 

My user macro with the following HTML code is just offering the download of the file:

<a href="/download/attachments/24281097/test.pptx?version=1&amp;modificationDate=1504962236837&amp;api=v2" data-linked-resource-id="24281098" data-linked-resource-version="1"  data-linked-resource-default-alias="test.pptx" data-nice-type="PowerPoint Presentation" data-linked-resource-content-type="application/vnd.openxmlformats-officedocument.presentationml.presentation" data-linked-resource-container-id="24281097" data-linked-resource-container-version="5">test.pptx</a>

What I want to try: writing a jQuery script to take out that attribute when no image is used. 

I will let you know if that is successful.

As a confluence user, not an administrator, I would prefer to have an option to disable the previewer in my user preferences, which would work independent of the administrator's decisions.

We (company with 4000 intranet users and 2 CONF instances) recently updated from CONF 5.5 to 5.10 and now we have a lot of complaints from users about that preview "feature". It is more a problem than helpful. I already rised some incidents at Atlassian about those bugs. In preview of PDF files text layers are not rendered. Users can't find a print function. Etc.

Created: 16/Mar/2015 3:14 PM and still not assigned.

It appears that there is not enough feedback for the Confluence users about this request.  What can be done to get more visibility on the ongoing issues with the document preview or disabling this 'feature'?

In general we would also like an option to prevent opening in the preview of a given attachment shown as link in a given page (and trigger download instead.

Hi noc12, viewing/previewing/downloading attachments is limited by the restrictions of the associated page.

If using the {attachments} macro, this displays a single page, the user will see "Page level restrictions have been applied that limit access to this page: restricted attachments" if they cannot view that page.

If using the {space attachments} macro, this will not display any attachments that reside on pages which the current user does not have permission to view.

If this does not help you diagnose your issue, please raise a support request

This is a serious permissions problem. One of our users has provided screen shots showing that the list of reports he's permitted to see is appropriate, but when he clicks on the link the preview pages clearly shows reports that he IS NOT PERMITTED TO SEE. This is a security issue for us. Please advise how we can disable this feature.

just found an ugly workaround: change the mime-type in the attachments properties to something undefined and confluence will show a download-dialog

We have also upgraded to a version of Confluence that has this 'feature' and since then I am receiving a lot of support requests to go back to 'click to download' functionality, especially for pdfs and large excel documents. The ideal solution would be to have the option to only enable this functionality for specific pages so that users who do like the functionality can still use it.

We are also waiting for this. The users do not accept the current situation without the pre-viewer function and also not with the functionality of the pre-viewer.
Please can you improve the situation soon?

Yea @Ross Bender you are doing it Good Luck.

Is there a way to get Atlassian feedback on this issue?

We have a number of types of files that don't work with the preview, so it would be nice to be able to specify which types to not attempt a preview as the users don't know what to do after it doesn't work.

I would also like to know how Confluence decides what to show next after the attachments on the current page have been looked through. If you keep hitting the arrows, suddenly you are previewing all sorts of files on other pages, in other spaces, and more than have nothing to do with where you are at. It would be best if the arrows would no longer work once the files attached to the current page are done.

I don't understand why this is marked as a suggestion. It is clearly a bug. Unchecking the two PDF options does not result in the expected behavior. PDFs still open in the Previewer and the attorneys in my law firm are having a cow. My only option as to Disable the entire add-on which has left everyone else unhappy.

When will this be fixed?

We have recently upgraded from 5.4 to 5.9.3 and are also facing this issue. Currently mostly prevalent with Powerpoint presentations.

We have recently upgraded from 5.0.3 to 5.7 and also facing this issue .
Please let us know when the fix will be availble

My company is upgrading to v5.9.x, and this new previewer "feature" is listed as a "known issue" and loss of functionality in the communications.

Used to be that attachments opened in the relevant application - pretty straightforward. Now, some attachments open in the previewer, and some produce the "We Can't Handle this File" message.

Excel files in the previewer sometimes display in a very misleading way. Inexplicably, text files (for which there's pretty much always an application) are among the "We Can't Preview this One" file types.

Assuming attachments are generally being produced by a somewhat standard set of applications in an organization, why would you force the organization to jump through these hoops? If most users in an organization have an attachment-producing application (Excel, for ex), we should be able to turn off the previewer for that file type and have the files either download or open directly, depending on the browser setting.

Not being able to preview a text file is just nutty less than optimal.

Vote this issue !!! agree with previous comments: This issue is affecting our users as well after upgrading to 5.8.10. I'd like to see this issue escalated and fixed by Atlassian.

The preview doesn't work properly on our documents, because you don't have our font installed. I'd like previewing to be an option when creating a link, not a forced default.

This is no suggestion but a bug, please fix the preview functionality so that previews can be disabled per extension or per file base.

You force our users to put files back into a Sharepoint instead of handling them in Confluence. I doubt that this is your intention.

This issue is affecting our users as well after upgrading to 5.8.13. I'd like to see this issue escalated and fixed by Atlassian.

Yes, restarting the server is one of the steps listed on https://confluence.atlassian.com/display/CONFKB/How+to+edit+bundled+or+system+plugins. If you're used to customising Confluence or JIRA I think it's overall a pretty straightforward change, especially if you have the luxury of doing this in a test environment before rolling out the upgrade to your users. But if this is not the case, or if you upgrade Confluence frequently, I could see this being an issue.

Rather than customising a plugin, it may be possible to instead do a workaround by injecting custom Javascript into the page. This could be done in Administration -> Look and Feel -> Custom HTML. The script could use jQuery to selectively turn off the click handlers installed by the Confluence Previews plugin. This approach would avoid the need to restart the server or re-apply the change after upgrading. Unfortunately I don't have time to look into this right now but might investigate it later on.

Hi Gareth, I assume Confluence will need to be restarted to see your change.

Though, I'm afraid I will not try it. This looks like becoming a support nightmare.

regards,
Hans-Peter

Here's what I did. This was in Confluence 5.8.13, so it might not work in other versions!

Disclaimer: This is not supported and may break your server. Always try it in a test environment first.

This is the change to disable the "preview" for most attachment links, while keeping it for images:

• Copy/unzip <confluence dir>\confluence\WEB-INF\atlassian-bundled-plugins\confluence-previews-1.2.12.jar
• Edit js\confluence\preview-support-min.js
• Comment out part of the line by changing this:

          return b.SELECTOR_STRINGS.IMAGE+", "+b.SELECTOR_STRINGS.EXTERNAL_IMAGE +", "+b.SELECTOR_STRINGS.FILE+", "+b.SELECTOR_STRINGS.LINK_FILE +", "+b.SELECTOR_STRINGS.ATTACHMENT_MACRO
  

  to this:

          return b.SELECTOR_STRINGS.IMAGE+", "+b.SELECTOR_STRINGS.EXTERNAL_IMAGE /*+", "+b.SELECTOR_STRINGS.FILE+", "+b.SELECTOR_STRINGS.LINK_FILE*/ +", "+b.SELECTOR_STRINGS.ATTACHMENT_MACRO
  

• Zip up the modified plugin and apply it as described on https://confluence.atlassian.com/display/CONFKB/How+to+edit+bundled+or+system+plugins
• You may need to refresh your browser cache to see the change. (Or there might be a way to force Confluence to regenerate batch.js - perhaps by clearing the plugins cache?)

To remove the preview links from "recently viewed" and "quick search" I used the following IIS URL rewrite rule.

• Install the URL Rewrite module
• Edit C:\Windows\System32\inetsrv\config\applicationHost.config, or wherever your IIS config file is located.
• Add this in the "<globalRules>" section. Alternatively, you could manually configure these rules in IIS Configuration Manager:

  <rule name="Rewrite attachment preview links" enabled="true" patternSyntax="ECMAScript" stopProcessing="true">
      <match url="^display/.*" />
      <conditions logicalGrouping="MatchAll" trackAllCaptures="true">
          <add input="{HTTP_HOST}" pattern="<hostname>" />
          <add input="{QUERY_STRING}" pattern="preview=%2F(.*)%2F(.*)%2F(.*)" ignoreCase="false" />
      </conditions>
      <action type="Redirect" url="http://<hostname>/pages/viewpageattachments.action?pageId={C:1}&amp;highlight={C:3}#attachment-{C:2}" appendQueryString="false" redirectType="Temporary" />
  </rule>
  <rule name="Rewrite attachment preview links (viewpage version)" stopProcessing="true">
      <match url="^pages/viewpage.action$" />
      <conditions logicalGrouping="MatchAll" trackAllCaptures="true">
          <add input="{HTTP_HOST}" pattern="<hostname>" />
          <add input="{QUERY_STRING}" pattern="pageId=.*&amp;preview=%2F(.*)%2F(.*)%2F(.*)" />
      </conditions>
      <action type="Redirect" url="http://<hostname>/pages/viewpageattachments.action?pageId={C:1}&amp;highlight={C:3}#attachment-{C:2}" appendQueryString="false" redirectType="Temporary" />
  </rule>
  
  

• Replace <hostname> with the host name of your Confluence server.

The first rule changes URLs like http://<hostname>/display/XX/YYY?preview=%2Faaaaaaaa%2Fbbbbbbbb%2Fcccccccc into http://<hostname>/pages/viewpageattachments.action?pageId=aaaaaaaa&highlight=ccccccccc#attachment-bbbbbbbb". The second rule does a similar thing with URLs that use "/viewpage.action" rather than "/display" - Confluence seems to use these URLs if the target page has a special character in its title.

You could do a similar thing in Apache but I'm not familiar with the syntax.

If you're not running Confluence behind a proxy server it may be possible to instead modify some templates in the built-in plugins or Confluence itself to change these URLs.

EDIT: Updated the rules to handle "viewpage" URLs in addition to "display" URLs.

the whole matter should be treated as a "bug" , not as a "suggestion", as earlier functionality has been broken.

Gareth, would you be so kind to share the rewrite rule and the js modification? I guess it would help quite a bit of people here. Well, myself I would definitely appreciate a workaround.

Thank you!

This issue was a showstopper for our upgrade from 5.3 to 5.8. In particular:

• Having Confluence "preview" PDF files provides no value, as Firefox, Chrome and IE9+ can already do it directly in the browser. In fact, the new behaviour is actually a regression as it prevents PDFs being previewed in IE9.
• The "preview" of Word and Excel files does not work for most of our files (it just says "cannot preview this file"). For those that it does work for, they often render incorrectly - especially spreadsheets. Plus it takes more time to generate the preview than it does to just download the file and view it in Word/Excel. Our users all have Office installed anyway, so there is little need to see a preview in Confluence.
• We have a lot of video files which Firefox and Chrome (and perhaps IE) can display directly in the browser. The new behaviour is a regression as it prevents these videos from being displayed in the browser.
• Depending on how you link to a file, the preview may or may not be displayed. For example, the preview applies to links to individual files on pages, on the "recently viewed" list or in the "quick search" results. But the links on the "view attachments" page, or from within the attachments macro, do not use the preview. Therefore, when a user clicks on a particular link on a page they cannot easily predict whether it is going to work or not. It may either (a) display the file directly in the browser, (b) display the Confluence preview with the issues mentioned above, or (c) prevent them displaying the file at all (if it's a PDF in IE9 or a video file).

Disabling the Confluence Preview plugin was not really an option for us as it:

• Breaks image previews (i.e. if you have a "small" version of an image on a page, you can no longer click on it to see the full version)
• Breaks attachment links from the "recently viewed" list (they just go to the attachments page, without highlighting or scrolling to the correct attachment)
• Breaks attachment links from the "quick search" (same problem as above).

As a workaround we resorted to:

• Modifying a .js file in the Confluence Preview plugin so that the preview only applies to images.
• Making a URL Rewrite rule to convert the "preview" links into "view attachment page and highlight the correct attachment" links. This makes the "recently viewed" and "quick search" links behave as they did in previous versions of Confluence.

It's rare that we have to put workarounds in place to disable new features when we upgrade our Confluence server, but we felt we had no alternative in this case.

Atlassian, I am facing the preview problem with PDF files after upgrading my instance from 5.6.6 to 5.7.1. It was working properly with 5.6.6 but getting error message "we can't preview this file. You will have to download it to preview"

Please provide the solution as soon as possible.

The main problem is that users become really VERY confused when they view a page now, which contains several different documents and types, even advanced users. They expect, when clicking a document on a certain page that the "known" dialogue will be initiated (i.e. save as or open with).
If you have for example 2 or more documents, clicking the first document will initiate the lightbox now and continues to display ALL documents on that particular page. This is not what a user would want: he doesn't expect a document gallery grouping independent documents all together in a lightbox.
It also takes time to load all these docs in a lightbox.
In addition it conflicts in context with other document plugins (i.e. GoEdit)
This is the feedback received from our users here.
We all expect lightboxes related mainly to images/graphics, but also here: as an editor I should be able to choose if I would want them to be grouped together or not. This already disturbed me somehow in previous lightbox versions...
Please, revert this "Feature" in the next Confluence version and provide a solution with config options where admins can select, which file type should be displayed in a lightbox (and automatically do not display a lightbox for those filetypes types NOT explicitely selected) And NO standard grouping please, neither for images nor for documents.
Let the admins choose if objects should be grouped.

Yes, I had the same thing with the scrollbar expecting it to move to the next page in a multi-page attachment that was being previewed. I also agree that the comment 'if you are in a hurry' - that's the whole point of having the preview, if you are in a hurry but the preview takes too long and isn't representative of the attachment in my case. Please make this function configurable at the space level. It's not fair to force a 'feature' onto all users when it doesn't actually work very well.

Similar as @ShelleyDee, I was also confused with the navigation of the new viewer. The arrows < and > open the next document, while I expected it to turn to the next page (I was viewing a powerpoint slideset).
It took me some time to find out that I have to use the scrollbar to get to the next page. In case of a powerpoint, this is unusual.
I think therefore, that the < and > arrows are more confusing than helpful.

Also, office documents can be very large. The new viewer is contra-productive on them, as it takes way too long to display even a 1MB office document. When people click onto a link of the file name, they expect the related application to open, not a viewer. Having to use the download link in the viewer ("If you are in a hurry") is kinda ridicule and will certainly lead to negative comments when we role out 5.7 to our users.
I think it should be configurable (site-wide) which document types should be handled by the viewer and which shouldn't.

I've spent half a day trying to make this work for me. I'm sure previously, the current worksheet opened when opening the attachment, but in the preview, the first worksheet is displayed. I was setting the page orientation and print area of the current worksheet which is quite similar to the first worksheet, so it took a while to realise this. Also, I've found the previewer takes just as long to display the file as downloading it, and it most cases, downloading it is required as it's a excel worksheet with many columns (too many to display in a preview) and different users would need to see different columns. Also for our in-house helpdesk, we are using Outlook templates, attached to confluence, but these cannot be previewed (which isn't helpful anyway in this case, they need to be downloaded) - so now the users get the error 'We can't preview this file. You'll have to download the file to view it.' - which has just added another step to our process. If the attachment is small enough to be previewed, I would embed it in the page anyway. we only attach files that need to be downloaded. It's really frustrating that our users have an extra step, and in the case of the outlook templates, they all think the functionality is completely broken, which has massively increased my workload in terms of email traffic in dealing with this.
If the attachments are supported as previews, just download them by default. Please make this functionality configurable ASAP. Also, for users of this, in terms of speed, is there a way to cache the preview so it doesn't take so long?

Amen. New features are good in most cases. However, if a new feature breaks something working, this is a bug.

I have had numerous complaints from inhouse users why the pages with donwload links to various types of documents are suddenly broken. For us, about half of the Word, Powerpoint and PDF-Files display as broken in the Lighgtbox. While this is to be expected - one can render only so much of Microsoft's plethora of features, this also implies that it is a bug to try and render these things anyways. For anything else than graphic files, lightbox preview should be off as a default and only be switched on on a case by case base in the wiki page. Additionaly, there is neither a way to switch back to the old behaviour nor to disable the feature altogether on a file type base.

So: BUG, please either reverte or make this thing configurable NOW.

Michael 'Very displeased with Atlassian's politics here' Elbel

Hello, we have the same problem with .pdf Files Preview Addon. In many cases, PDF files remain black in the preview and are not displayed. First, you search for pdf file, then you click on the right result entry. Then you get the site with the attachment, after secondes the preview plugin shows only the black lightbox without the PDF-File. We need as soon as possible a solution to fix this problem. Proposal one, how can we use the old behavior, you search for files and you get the result with a marked line. Proposal two, we need a fix of the "Confluence Previews - Version 1.1.33"
part of the screenshot attachment. the rest of the picture is also black. No PDF File shown!

The new file preview makes a lot of use cases unusable. The gallery macro can be used in editor mode but is not working in view mode because of the file preview feature. If users try to view an image in context of a document the user gets all attachments shown which makes usability awefull and difficult.

At this rate customer will not be able to use their known behaviors for documentations because the file viewer breaks through the logic of usabilty. Please consider a fall back feature were customers can choose which methode they prefer. The known usability for viewing images or the new modern method of getting all attachment in one view.

The new way of handling attachments was the reason of a considerable discontent among our non technical users.
As you know, any change with the less tech savvy crowd is a source of complaints. And when something stops working - you can imagine what we have got when we have upgraded.

My understanding is that Atlassian aims at penetrating non technical corporate market. It is a commendable aspiration. Yet to achieve that one needs to take extra care to avoid such slip ups.

Please also refer to https://jira.atlassian.com/browse/CONF-37109 which seems to cover the same issue.

In our environment the "upgrade" to the lightbox really felt like a step backwards from our end user's perspective and I think that this may help repair some of that.

In our enterprise environment we primarily use Windows 7 and Internet Explorer 9. Prior to upgrading to Confluence 5.7 we had a great number of PDF's published as links on our confluence pages. The intent here was to have a repository of PDF documents which contained information which was made extremely easy to find by leveraging the search capabilities of confluence. Find the file, download the file, read the file to find the information you were looking for pretty simple. After upgrading however, we got the new lightbox, and while it changed visually a little bit all was working as expected... until we went to our PDF documents to download them.

Now, because the lightbox is also attempting to bring up a preview of a pdf document, all of our IE9 users are now given a big ugly message saying that Internet Explorer 9 isn't supported download the file, instead of simply automatically downloading the file. So in the update to the lightbox, while nice for more modern browsers, caused a complete mess with our existing environment and the usability of it.

As a workaround we currently have the "Confluence Previews" add-on completely disabled. However, doing this we've completely lost our ability to view images in a lightbox which makes all these tiny thumbnails we have in our documentation kind of useless.

Ideally it would be nice to just have the document download automatically if it's not supported by the browser in the new lightbox, but being able to toggle what's displayed and what isn't I suppose is the next best thing.