837512 - Syntax highlighting is not available in JS files that do not end with '.js' even if Content-Type is 'text/javascript'

Status: RESOLVED DUPLICATE of bug 786834

(DevTools :: Debugger, defect)

Description

[Brian Di Palma]

I'm creating a Node JS 'bundler' which is basically going to concatenate all the JS that a project requires on the fly i.e. with no build step.

I have an index.html webpage with a special script tag that my Node code responds to with the concatenated blob.

The script tag was

<script src="js.bundle"></script>

But I've had to change it to 

<script src="bundle.js"></script>

to get any syntax highlighting in the FF Debugger console as setting the content-type to 'text/javascript' wasn't enough.

Surely if something is of content type 'text/javascript' it should be highlighted as such in the Debugger?

Comment 1

[Panos Astithas (he/him) [:past] (please ni?)]

This is a known issue that appeared when we moved source fetching to the backend.

Comment 2

[Victor Porof [:vporof][:vp]]

In the meantime, we could default to js highlighting for files without a content type and not starting with a "<", but I'm not sure if that's such a good idea.

Comment 3

[Brian Di Palma]

Well I've modified debugger-view.js in the obj directory after doing a FF build so that in everyplace it does setMode for the Debugger it sets it to JS mode and that doesn't seem to make any difference at all so I'm a bit confused as to where the code that does what I want is!

You also show "loading.." as text when the page hasn't loaded fully even though Firebug does show JS text, I tried to see if setting the editor text to the js source.text attribute would show some JS text but it shows a blank.

I would ideally like to help fix these issue but I think my lack of knowledge about the debugger internals is too great.

Comment 4

[Victor Porof [:vporof][:vp]]

(In reply to Brian Di Palma from comment #3)
> Well I've modified debugger-view.js in the obj directory after doing a FF
> build so that in everyplace it does setMode for the Debugger it sets it to
> JS mode and that doesn't seem to make any difference at all so I'm a bit
> confused as to where the code that does what I want is!
> 

The function is DV_setEditorMode in debugger-view.js, replace
> this.editor.setMode(SourceEditor.MODES.TEXT);
with
> this.editor.setMode(SourceEditor.MODES.JAVASCRIPT);

If your files are > 1Mb, you'll also need to change DV_setEditorSource.

This is just a workaround for your convenience, the actual fixing needs to be done in bug 786834.

Comment 5

[Brian Di Palma]

Yep Victor I did do that and it didn't seem to work so I reverted the file changes and tried to bring up the debugger and that failed totally. Once I started the normal Nightly build and shut it down the next time I started my build the debugger worked and putting my changes back in worked. So that's cool.

Really weird, some sort of profile issue maybe.

I'm a bit confused as to why you have the default value for the editor be TEXT, I mean this is a debugger-view. Therefore if you are inspecting something using the debugger one would presume that more then likely JavaScript. Is that reasonable or would it be used to inspect normal text in the majority of cases?

Comment 6

[Brian Di Palma]

By the way 1Mb is very small, the files I am using to debug the issue are all below that but you could easily hit that much JS in a production single page application if you concatenate it.

Comment 7

[Panos Astithas (he/him) [:past] (please ni?)]

(In reply to Victor Porof [:vp] from comment #2)
> In the meantime, we could default to js highlighting for files without a
> content type and not starting with a "<", but I'm not sure if that's such a
> good idea.

I think fixing bug 786834 should be straightforward enough to not require any workarounds.

(In reply to Brian Di Palma from comment #5)
> I'm a bit confused as to why you have the default value for the editor be
> TEXT, I mean this is a debugger-view. Therefore if you are inspecting
> something using the debugger one would presume that more then likely
> JavaScript. Is that reasonable or would it be used to inspect normal text in
> the majority of cases?

I think it makes sense to treat unknown content types without syntax highlighting. That's what the default is for. The fact that JS content is of unknown type is the problem here.

(In reply to Brian Di Palma from comment #6)
> By the way 1Mb is very small, the files I am using to debug the issue are
> all below that but you could easily hit that much JS in a production single
> page application if you concatenate it.

The limit is there to work around an Orion bug with highlighting large documents. We intend to remove it when that bug is fixed. 1MB was a guestimate based on our own experience, but we can certainly tune it further. What would be a reasonable limit in your opinion? Note that concatenated JS is usually minified, which will make debugging problematic, until we have implemented source maps.

Comment 8

[Brian Di Palma]

I looked at the Orion Github page and I couldn't see an issues page.
Which is a pity as I would like to take a gander at their code base
and attempted to understand the 1Mb bug. Mind you I'd guess it's some sort of 
performance issue which would not yield easily.

One of our gzipped demo apps weights in at 1.08Mb. I guess that after it's unzipped
it would take up more. I also guess that the FF Network Result specifies size before unzipping?

We have just one script tag with everything concatenated even in dev, it happens
with no build step. So if you use some new code and press F5 you will get it automagically. At the moment all we do is gzip. We basically parse the JS
and pull in any JS file you need by references. We namespace our
classes by directory just like in Java. I'm just writing an open source one
for Node as I think it might help other people creating large applications.

I wouldn't change the 1Mb limit based on our use case as I think we are
probably a special case. We had to write server side code to allow the 
automagic concatenation of all our JS - I would guess most places wouldn't
take this approach.