Feature #25357
open
"Raw view" of a file in repository
Added by Vasili Korol about 7 years ago.
Updated almost 7 years ago.
Description
Right now one can "view" a file in the repository - this shows the source code with line numbers, syntax highlighting etc.
But I think it will also be a nice feature to display "raw" file source in the browser window (basically show the file as plain text in another tab). Github has this feature, and it's quite convenient, because it allows easy copy-pasting (without the line numbers and tabs) and makes use of browser plugins (like Sight for Google Chrome) to highlight the code in a way the user prefers.
Files
- Related to Feature #25999: View repository content by default (instead of the history) added
I think we can integrate this feature with #25999.
- Target version set to Unplanned backlogs
This feature would be a very nice addition indeed. However, the by Go MAEDA proposed link location would conflict with #26035. I also don't think that it's a good idea to place the link in the contextual area too — like proposed for the download link in #26035, since it would clutter up that space with too many links IMHO.
@Go MAEDA: do you have actual code integrating such a 'raw view' or is it just a mockup?
- Related to Feature #26035: More visually consistent download links added
Mischa The Evil wrote:
@Go MAEDA: do you have actual code integrating such a 'raw view' or is it just a mockup?
No, I have not wrote any code yet. The screenshot is just a rough sketch made with a developer tool of a web browser. I will be happy to see new ideas.
When implementing this, we have to make sure to not introduce subtle security issues:
- All raw files have to be served either as
text/plain for text files or application/octet-stream for binary files. Probably, we shouldn't even offer the raw display of binary files since they couldn't be meaningfully displayed by the browser anyway, but use the "download" option there instead.
- We have to make sure that browsers don't attempt to guess the content type of the file on their own, using response headers like
X-Content-Type-Options: nosniff
If we serve raw files with their own content types inline, we would re-introduce the problems previously fixed in r16285.
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by 
Updated by