PDF file download problem

[mspalti]

Describe the bug I'll report this as an Angular UI issue to start the discussion, but aspects of the REST API are also involved.

Currently, when the user choses to download a PDF file (and probably other file formats that can be rendered inline in the browser) the bitstream download page is opened followed by a hard redirect to the REST API content endpoint. In the case of a PDF, the REST API response Content-Disposition header usually indicates an inline resource and the PDF file is rendered in the browser window.

There are 2 problems with this.

1. Two clicks in the browser navbar are required to return to the DSpace Item page; the first back click results in the PDF file being rendered again a second time.
2. If the bitstream has access restrictions, the first click instead results in a WhiteLabel page indicating a 401 error.

One possible solution for #1 is to open the bitstream download page in a new browser tab. This can be done easily a themed version of file-section-component.html by adding isBlank=true to attributes of theds-download-link element. We might want to consider making this change in the default component.

Unfortunately, if bitstream access is restricted, opening the download page in a new tab also results in #2 (the 401 error ) so more work would be required to make this solution work.

There may be other, better ways to solve the navigation problem.

To Reproduce Steps to reproduce the behavior:

1. Click to download a PDF file in the simple Item view
2. Once open, use the browser back button to navigate back to the item
3. Try the same thing again on a bitstream with restricted access and you should see a 401 error.

Expected behavior The download page serves a useful purpose so ideally everything would remain as is with the exception of fixing the 2-click return problem for inline files. Alternately, opening the download page in a new tab an acceptable compromise once the authorization error is fixed. There may be other solutions.

Related work Link to any related tickets or PRs here.

[mwoodiupui]

Re: the "usually" above: inline vs. attachment is affected by the value of webui.content_disposition_threshold. Testing with a sufficiently large bitstream will result in different browser behavior.

[tdonohue]

This is related to #1004, which is the original creation of the Bitstream download page.

@artlowel : Pinging you as I know your team built the bitstream download page in #1004, so I wonder if you'd have thoughts on how to improve the usability per this ticket.

In the meantime, I'll also pull this over to our 7.4 board, as I feel this might be nice to improve if there's a quick solution available. If not, we may need to consider moving it to 7.5

[mspalti]

Quick note: my description of the "2-click" issue is based on the Chrome browser; the behavior might be a bit different in Firefox and other browsers.

fyi, I'm currently following @mwoodiupui's suggestion and setting the backend's webui.content_disposition_threshold to zero, which forces the attachment header in all cases. This seems to work well enough if a solution doesn't find its way into in 7.4. (Honestly, downloading as an attachment is an easier sell to users at this university, especially because 95% of the PDF files here are access restricted and the authorization error is a bit of a blemish when exposed to users. From what I've seen so far, browsers make it pretty easy to open and view the downloaded file.)

[tdonohue]

Closing, this is no longer reproducible in 7.5. I believe it was fixed by the fix for #1809