Details
-
Improvement
-
Status: Resolved (View Workflow)
-
Minor
-
Resolution: Fixed
-
-
pannonian
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
- Browse to a build that has produced artifacts (test.html, test.blob).
- Click on test.html (it will be viewed)
- 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
This can use HTML5 download attribute but support is still spotty (thanks Safari) so really depends on support:
http://caniuse.com/#feat=download
https://davidwalsh.name/download-attribute
We should also make the artifact name a link https://news.ycombinator.com/item?id=13219097
There is no artifact name as a link. Now we are unable to view it, just download.
kamikaze good catch. It is fixed now in https://github.com/jenkinsci/blueocean-plugin/pull/781
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.
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).
michaelneale is there some sort of backend change that required here?