Uploaded image for project: 'Jenkins'
  1. Jenkins
  2. JENKINS-36783

Artifact download links rely on mime type to determine download vs. view

    Details

    • Sprint:
      pannonian
    • Similar Issues:

      Description

      Fix download to actually download, and clicking on artifact name to show OR download.

      In scope:

      • Clicking on download should always result in a download
      • Clicking on artifact name should open the artifact in a new tab (as now) IFF the browser knows how to render (ie the current behavior for download link should be transferred to name)

      Out of scope:

      • Moon landing.

      HTML5 download attribute (as mentioned below) is probably fine to use.

      Reproduction notes:

      Procedure

      1. Browse to a build that has produced artifacts (test.html, test.blob).
      2. Click on test.html (it will be viewed)
      3. Click on test.blob (it will be downloaded)

      Expected

      Clicking on the artifact "download" link should always download the artifact. A download (and filename) should be forced using Content-Disposition (from the server) or a HTML5 download=FILENAME attribute (client).

      Clicking on the artifact name should do what the current download icon does - ie download or show (if the browser knows how to render the content type).

      How this is implemented depends if server side header or html5 download is used.

      Actual

      Some mime-types are downloaded, some are viewed

      *.html are opened for view, *.unknown are downloaded.

        Attachments

          Activity

          Hide
          jamesdumay James Dumay added a comment -

          Michael Neale is there some sort of backend change that required here?

          Show
          jamesdumay James Dumay added a comment - Michael Neale is there some sort of backend change that required here?
          Hide
          michaelneale Michael Neale added a comment -
          Show
          michaelneale Michael Neale added a comment - This can use HTML5 download attribute but support is still spotty (thanks Safari) so really depends on support: http://stackoverflow.com/questions/6794255/html-download-a-pdf-file-instead-of-opening-them-in-browser-when-clicked http://caniuse.com/#feat=download https://davidwalsh.name/download-attribute
          Hide
          jamesdumay James Dumay added a comment -

          We should also make the artifact name a link https://news.ycombinator.com/item?id=13219097

          Show
          jamesdumay James Dumay added a comment - We should also make the artifact name a link https://news.ycombinator.com/item?id=13219097
          Hide
          kamikaze Oleg Korsak added a comment -

          There is no artifact name as a link. Now we are unable to view it, just download.

          Show
          kamikaze Oleg Korsak added a comment - There is no artifact name as a link. Now we are unable to view it, just download.
          Hide
          tscherler Thorsten Scherler added a comment -
          Show
          tscherler Thorsten Scherler added a comment - Oleg Korsak good catch. It is fixed now in https://github.com/jenkinsci/blueocean-plugin/pull/781
          Hide
          kamikaze Oleg Korsak added a comment -

          Thanks )

          Show
          kamikaze Oleg Korsak added a comment - Thanks )
          Hide
          ssbarnea Sorin Sbarnea added a comment - - edited

          Maybe someone can give me a hint on this: I observed that for .log files Jenkins works as expected but I do also have shell files (.sh) which are always downloaded, even when I click the view link (left side).

          Where can this be changed so people can view these files?

          I have the impression that this bug was not really sorted because Jenkins should be able to return different Content-Disposition header for the left side links  (view), and for right side (download). 

          At this moment these urls look identical which makes me believe there is no way for jenkins to know what headers to return.

          I do remember that the old UI had different URLs, so this seems like a UX regression from this point of view.

          Show
          ssbarnea Sorin Sbarnea added a comment - - edited Maybe someone can give me a hint on this: I observed that for .log files Jenkins works as expected but I do also have shell files (.sh) which are always downloaded, even when I click the view link (left side). Where can this be changed so people can view these files? I have the impression that this bug was not really sorted because Jenkins should be able to return different Content-Disposition header for the left side links  (view), and for right side (download).  At this moment these urls look identical which makes me believe there is no way for jenkins to know what headers to return. I do remember that the old UI had different URLs, so this seems like a UX regression from this point of view.
          Hide
          michaelneale Michael Neale added a comment -

          Sorin Sbarnea it may be a regression, in which case do you mind opening a new ticket? I wasn't able to reproduce it myself (it maybe some browser subtlety). 

          Show
          michaelneale Michael Neale added a comment - Sorin Sbarnea it may be a regression, in which case do you mind opening a new ticket? I wasn't able to reproduce it myself (it maybe some browser subtlety). 

            People

            • Assignee:
              tscherler Thorsten Scherler
              Reporter:
              bwalding Ben Walding
            • Votes:
              1 Vote for this issue
              Watchers:
              5 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved: