Attachment are always triggerd to download #1198

New Issue

OVERLORD · 2026-02-05T00:14:05+03:00

OVERLORD commented

2026-02-05 00:14:05 +03:00

Originally created by @JtheBAB on GitHub (May 24, 2019).

Describe the bug
When clicking to a attachment it always offers to download instead of using the default browser settings.

Steps To Reproduce
Steps to reproduce the behavior:

Go to a page with an attachment (pdf)
Click on the attachment link
Attachment is offered as a download instead of respecting the default behavior of the browser

Expected behavior
Bookstack should respect the default behavior of the browser. In my case open the PDF with the inbuild PDFReader from FireFox.

Your Configuration (please complete the following information):

Exact BookStack Version (Found in settings): 0.26.1
PHP Version: 7.3
Hosting Method (Nginx/Apache/Docker): Apache

Originally created by @JtheBAB on GitHub (May 24, 2019). **Describe the bug** When clicking to a attachment it always offers to download instead of using the default browser settings. **Steps To Reproduce** Steps to reproduce the behavior: 1. Go to a page with an attachment (pdf) 2. Click on the attachment link 3. Attachment is offered as a download instead of respecting the default behavior of the browser **Expected behavior** Bookstack should respect the default behavior of the browser. In my case open the PDF with the inbuild PDFReader from FireFox. **Your Configuration (please complete the following information):** - Exact BookStack Version (Found in settings): 0.26.1 - PHP Version: 7.3 - Hosting Method (Nginx/Apache/Docker): Apache

OVERLORD added the ☕ Open to discussion label 2026-02-05 00:14:05 +03:00

OVERLORD closed this issue

2026-02-05 00:14:06 +03:00

OVERLORD commented

2026-02-05 00:14:08 +03:00

@ssddanbrown commented on GitHub (May 25, 2019):

Thanks for the report @JtheBAB.

To be honest this is purposeful, to standardise how all attachments are handled. As soon as you stop forcing this behaviour it becomes unreliable as different file types will behave differently then this is multiplied by how browsers will handle those different file types in a different manner.

@ssddanbrown commented on GitHub (May 25, 2019): Thanks for the report @JtheBAB. To be honest this is purposeful, to standardise how all attachments are handled. As soon as you stop forcing this behaviour it becomes unreliable as different file types will behave differently then this is multiplied by how browsers will handle those different file types in a different manner.

OVERLORD commented

2026-02-05 00:14:11 +03:00

@JtheBAB commented on GitHub (May 27, 2019):

Hi @ssddanbrown

I see your point. But i think it would be better when the user settings are respected.

It came just now in my mind:

I don't know how complicated it is but why not add a setting on the "edit profile" page to control if it should be forced (default) or free?

@JtheBAB commented on GitHub (May 27, 2019): Hi @ssddanbrown I see your point. But i think it would be better when the user settings are respected. It came just now in my mind: I don't know how complicated it is but why not add a setting on the "edit profile" page to control if it should be forced (default) or free?

OVERLORD commented

2026-02-05 00:14:18 +03:00

@ssddanbrown commented on GitHub (May 27, 2019):

I see your point. But i think it would be better when the user settings are respected.

The trouble is, that it's often not up to the user. It's often up the browser and the overall users' system.

I don't know how complicated it is but why not add a setting on the "edit profile" page to control if it should be forced (default) or free?

Would not be complicated to add but extra settings can be a burden on maintenance & support while opening the floodgates to more settings. Additionally, I'd imagine that admins in many multi-user environments would prefer consistency over user preference.

Perhaps we can look at achieving this in a different manner. The attachment link behaviour could stay as-is but have a little dropdown icon next to the attachment to select download type, Or a key modifier so a ctrl+click (Default open in new tab shortcut) opens it using browser behaviour.

@ssddanbrown commented on GitHub (May 27, 2019): > I see your point. But i think it would be better when the user settings are respected. The trouble is, that it's often not up to the user. It's often up the browser and the overall users' system. > I don't know how complicated it is but why not add a setting on the "edit profile" page to control if it should be forced (default) or free? Would not be complicated to add but extra settings can be a burden on maintenance & support while opening the floodgates to more settings. Additionally, I'd imagine that admins in many multi-user environments would prefer consistency over user preference. Perhaps we can look at achieving this in a different manner. The attachment link behaviour could stay as-is but have a little dropdown icon next to the attachment to select download type, Or a key modifier so a ctrl+click (Default open in new tab shortcut) opens it using browser behaviour.

OVERLORD commented

2026-02-05 00:14:23 +03:00

@JtheBAB commented on GitHub (May 27, 2019):

Sounds good :)

@JtheBAB commented on GitHub (May 27, 2019): Sounds good :)

OVERLORD commented

2026-02-05 00:14:25 +03:00

@mattkerrison commented on GitHub (Sep 30, 2019):

Please implement this! PDFs just download instead of opening in a new tab, it’s so painful

@mattkerrison commented on GitHub (Sep 30, 2019): Please implement this! PDFs just download instead of opening in a new tab, it’s so painful

OVERLORD commented

2026-02-05 00:14:26 +03:00

@APlueckthun commented on GitHub (Apr 28, 2020):

It would be extremely (!) appreciated by all of the users of BookStack in our place, if PDFs can be viewed inline, as opposed to being dowloaded.
Why is this so important? We typically link scientific papers as PDFs, and without opening it, you cannot know whether this paper contains what you want. At the end, the download folder is full of PDFs. Conversely, if the PDF is opened inline, you can choose to download it, or let it disappear once the browser is closed.
We consider this the single biggest drawback of BookStack! And it would probably be easy to implement! And you would make a large numbers of users happy!

@APlueckthun commented on GitHub (Apr 28, 2020): It would be extremely (!) appreciated by all of the users of BookStack in our place, if PDFs can be viewed inline, as opposed to being dowloaded. Why is this so important? We typically link scientific papers as PDFs, and without opening it, you cannot know whether this paper contains what you want. At the end, the download folder is full of PDFs. Conversely, if the PDF is opened inline, you can choose to download it, or let it disappear once the browser is closed. We consider this the single biggest drawback of BookStack! And it would probably be easy to implement! And you would make a large numbers of users happy!

OVERLORD commented

2026-02-05 00:14:32 +03:00

@APlueckthun commented on GitHub (May 10, 2020):

Any way this is implemented is good. Whether this via the default browser setting or via an individual icon next to the link (download / inline view), both would be fine.
But please implement this.

@APlueckthun commented on GitHub (May 10, 2020): Any way this is implemented is good. Whether this via the default browser setting or via an individual icon next to the link (download / inline view), both would be fine. But please implement this.

OVERLORD commented

2026-02-05 00:14:39 +03:00

@rfrye commented on GitHub (Aug 3, 2020):

I agree that the force download of PDF is a pain point for me. I dont have the solution for you, maybe a dropdown menu like you mentioned. Just wanted to be a voice that says its a pain point.
Love Bookstack

@rfrye commented on GitHub (Aug 3, 2020): I agree that the force download of PDF is a pain point for me. I dont have the solution for you, maybe a dropdown menu like you mentioned. Just wanted to be a voice that says its a pain point. Love Bookstack

OVERLORD commented

2026-02-05 00:14:43 +03:00

@APlueckthun commented on GitHub (Aug 4, 2020):

The resistance against implementing this change comes from the desire to treat all attachments the same. But this is the source of all misunderstanding. While most file types (.xlsx, .doc., or attached text files of any denomination) make no sense with anything else but download, PDFs are fundamentally different. PDFs are typically to be looked at, read, and not edited or worked upon. This is the very reason why many browsers have options to view them inline.

The only thing we are asking for is to not overwrite this feature of the browser.

And to only do this for the file type PDF.

And if a browser does not support in line viewing, or the user has set other preferences, it gets downloaded anyway, so where is the damage?

If one is using BookStack for linking to lots of PDFs for the user to read up in depth on certain points, why prevent doing this in line? Why force the user to clutter his download folder with lots of PDFs, which then become unlinked to the original BookStack entry?

I still hope this can be rectified. I just cannot discover any harm when treating PDFs separately from other file types, if the user has set his browser preferences accordingly.

Many thanks for reconsidering this! It would GREATLY enhance BookStacks (which is really great otherwise).

@APlueckthun commented on GitHub (Aug 4, 2020): The resistance against implementing this change comes from the desire to treat all attachments the same. But this is the source of all misunderstanding. While most file types (.xlsx, .doc., or attached text files of any denomination) make no sense with anything else but download, PDFs are fundamentally different. PDFs are typically to be looked at, read, and not edited or worked upon. This is the very reason why many browsers have options to view them inline. The only thing we are asking for is to not overwrite this feature of the browser. And to only do this for the file type PDF. And if a browser does not support in line viewing, or the user has set other preferences, it gets downloaded anyway, so where is the damage? If one is using BookStack for linking to lots of PDFs for the user to read up in depth on certain points, why prevent doing this in line? Why force the user to clutter his download folder with lots of PDFs, which then become unlinked to the original BookStack entry? I still hope this can be rectified. I just cannot discover any harm when treating PDFs separately from other file types, if the user has set his browser preferences accordingly. Many thanks for reconsidering this! It would GREATLY enhance BookStacks (which is really great otherwise).

OVERLORD commented

2026-02-05 00:14:49 +03:00

@ssddanbrown commented on GitHub (Jun 13, 2021):

Within BookStack v21.05.2 it's now possible to open up attachments in an "inline" (Not forced download) via Ctrl+Click of the attachment (Or Cmd+click on Mac). Alternatively, an attachment link of this type can be manually formed by adding an ?open=true query parameter to the link.

I'd still like to add some UI to the attachment items themselves so the access type can be chosen more intuitively (With better accessibility) but I could not come up with an approach I was happy with right now, Will need to have a deeper think about this from a design/accessibility perspective.

@ssddanbrown commented on GitHub (Jun 13, 2021): Within BookStack [v21.05.2](https://github.com/BookStackApp/BookStack/releases/tag/v21.05.2) it's now possible to open up attachments in an "inline" (Not forced download) via Ctrl+Click of the attachment (Or Cmd+click on Mac). Alternatively, an attachment link of this type can be manually formed by adding an `?open=true` query parameter to the link. I'd still like to add some UI to the attachment items themselves so the access type can be chosen more intuitively (With better accessibility) but I could not come up with an approach I was happy with right now, Will need to have a deeper think about this from a design/accessibility perspective.

OVERLORD commented

2026-02-05 00:14:52 +03:00

@npankaj365 commented on GitHub (Aug 30, 2022):

For anyone wanting to loading PDF on side, I created the following snippet that implements what @ssddanbrown has shared.
Sharing it here for reference if anyone's struggling. Placing this inside Custom HTML Head Content does the job.

function previewPDF(item)
    {
        if( item.innerText.includes('.pdf'))
        {
            item.href += "/?open=true";
        }
    }
	window.onload = function(){
  		document.querySelectorAll('a').forEach(previewPDF);
    };

@npankaj365 commented on GitHub (Aug 30, 2022): > For anyone wanting to loading PDF on side, I created the following snippet that implements what @ssddanbrown has shared. Sharing it here for reference if anyone's struggling. Placing this inside Custom HTML Head Content does the job. ``` function previewPDF(item) { if( item.innerText.includes('.pdf')) { item.href += "/?open=true"; } } window.onload = function(){ document.querySelectorAll('a').forEach(previewPDF); }; ```

OVERLORD commented

2026-02-05 00:14:55 +03:00

@ssddanbrown commented on GitHub (Aug 30, 2022):

I'm going to go ahead and close this off as the agreed upon implementation, as per my comment above, was essentially added as of v22.06.

@ssddanbrown commented on GitHub (Aug 30, 2022): I'm going to go ahead and close this off as the agreed upon implementation, [as per my comment above](https://github.com/BookStackApp/BookStack/issues/1464#issuecomment-496200398), [was essentially added as of v22.06](https://www.bookstackapp.com/blog/bookstack-release-v22-06/#attachment-link-dropdown).

Sign in to join this conversation.

Branches Tags

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/BookStack#1198