660193 - Improve view-source protocol for .js, .json, .css files

Status: NEW

(DevTools :: Source Editor, defect, P3)

Description

[Irakli Gozalishvili [:irakli] [:gozala] [@gozala]]

Currently veiw-source: on .js .json and .css files is absolutely useless in fact there is no diff between two:

view-source:https://github.com/Gozala/graphquire/raw/v0.3.0/graphquire.js
https://github.com/Gozala/graphquire/raw/v0.3.0/graphquire.js

Small improvements like syntax highlighting and line numbers would make a huge difference!

Comment 1

[Rob Campbell [:rc] (:robcee)]

I'm going to move this into the source editor component. This is still an issue.

Comment 2

[Jordan Santell [:jsantell] [@jsantell]]

Discussion of using codemirror for this was had, which would solve this with nice syntax highlighting.

Comment 3

[Jeff Griffiths (:canuckistani) (:⚡︎)]

If we do this, are we considering doing it for html view source as well? It would be great if the syntax highlighting matched the user's theme settings.

Comment 4

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

(In reply to Jeff Griffiths (:canuckistani) from comment #3)
> If we do this, are we considering doing it for html view source as well? It
> would be great if the syntax highlighting matched the user's theme settings.

That would be my assumption: we would likely transition to the same (read-only) editor-like thing (most likely our source editor widget) for all file types, including HTML, and highlighting, etc. would be based on whatever that editor does for different file types.

The current HTML view source tool is not easily extensible for other file types at all.  It's a special mode of Gecko's HTML parser, so there's no obvious way to just "enable" JS, etc. support.  Something would need to parse the JS, emit tags for highlighting, etc. which editors already know how to do.

One problem we'd have to contend with is that the current HTML view source is able to handle very large documents efficiently because of its design.  Some people (at least bz, IIRC) would be sad if the new approach was slow for these cases.

Some day this could also tie into our plans for a resources view in the toolbox, in which case it could be a true editor, not just read-only.

Comment 5

[J. Ryan Stinnett [:jryans] (Use needinfo, replies may be slow)]

Switching to an editor in general would not be too hard here, but I've learned there are many edge cases with view source and extra features I wasn't originally aware of.  Also, we need to be sure of the perf, as in comment 4.