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

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

XMLWordPrintable

    • pannonian

      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.

        1. image (1).png
          image (1).png
          12 kB

          [JENKINS-36783] Artifact download links rely on mime type to determine download vs. view

          James Dumay added a comment -

          michaelneale is there some sort of backend change that required here?

          James Dumay added a comment - michaelneale is there some sort of backend change that required here?

          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

          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

          James Dumay added a comment -

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

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

          Oleg Korsak added a comment -

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

          Oleg Korsak added a comment - There is no artifact name as a link. Now we are unable to view it, just download.

          Thorsten Scherler added a comment -

          kamikaze good catch. It is fixed now in https://github.com/jenkinsci/blueocean-plugin/pull/781

          Thorsten Scherler added a comment - kamikaze good catch. It is fixed now in https://github.com/jenkinsci/blueocean-plugin/pull/781

          Oleg Korsak added a comment -

          Thanks )

          Oleg Korsak added a comment - Thanks )

          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.

          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.

          Michael Neale added a comment -

          ssbarnea 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). 

          Michael Neale added a comment - ssbarnea 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). 

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

              Created:
              Updated:
              Resolved: