Feature #25357
open"Raw view" of a file in repository
0%
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 issues
Updated by Go MAEDA over 7 years ago
- Related to Feature #25999: View repository content by default (instead of the history) added
Updated by Go MAEDA over 7 years ago
I think we can integrate this feature with #25999.
Updated by Mischa The Evil over 7 years ago
- 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?
Updated by Mischa The Evil over 7 years ago
- Related to Feature #26035: More visually consistent download links added
Updated by Go MAEDA over 7 years ago
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.
Updated by Holger Just over 7 years ago
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 orapplication/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.