1450205 - Trunk: |Tools > Developer Tools > Error Console| - Click on JS file link to open in external viewer doesn't work in server build

Status: RESOLVED DUPLICATE of bug 1454041

(Thunderbird :: General, defect)

Description

[Jorg K (CEST = GMT+2)]

+++ This bug was initially created as a clone of Bug #1448489 +++

This is the reverse of bug 1448489 :-(

Tools > Developer Tools > Error Console. Now click onto any JS file link listed in the log.

You get:
TypeError: this.gViewSourceUtils is undefined hudservice.js:400:5

That line is:
  viewSource(sourceURL, sourceLine) {
400 this.gViewSourceUtils.viewSource({ URL: sourceURL, lineNumber: sourceLine || 0 });
  },

Note that opening source is not quite working in TB in general, you need to set
view_source.editor.external to true and view_source.editor.path. I use C:\Program Files (x86)\Notepad++\notepad++.exe.

If you do that, you can open the JS file in an external editor in a *local* build. It doesn't work on a server build.

Alice, could to please see when that broke. It wasn't working on in builds on the 26th of March (if I'm not mistaken). If you have an empty console with nothing to click on, do this. Type |print p|, hit enter twice. Then click on "Learn more" (which also doesn't work, bug 1427590). That will give you an error to click on.

Julian, are you aware of any changes in that area? Or perhaps I should ask the "view source" people.

Comment 1

[Richard Marti (:Paenglab)]

A workaround, until this is fixed, would be to use the Developer Toolbox. Go to Console tab and click on the right on the error source. Now the Debugger tab opens with the source code and jumps to the line. The line is only highlighted for a short time but clicking on the eye symbol below the code highlights it again.

Comment 2

[Julian Descottes [:jdescottes]]

Looking at Bug 1427590, the chromeUtilsWindow available to hudService misses some expected properties. At least gViewSourceUtils and openUILinkIn. I believe this bug and Bug 1427590 are linked. Comments in Bug 1427590 indicate this is an old issue. Can we get a regression window for this issue as well?

Looking at the code responsible for loading the Browser Console window, I don't see an obvious issue. For the new frontend we load a html file via Services.ww.openWindow(...). For the old frontend we were loading a xul file. Maybe this had an impact? Again I would prefer to investigate with a regression window here, because I don't see anything obvious.

Comment 3

[Alice0775 White]

regression window:
https://hg.mozilla.org/comm-central/pushloghtml?fromchange=a1baa186817e2d25b6090a7800814932d326f176&tochange=2dc101e7eddc3ebfc0e470f4d4a53b40cefff464
https://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=0b997836c7cf258a2b821eaa1c1ee66b9289ab17&tochange=bfb7edfd0436db388bb9e103b8ad817fc50bfdcf

Comment 4

[Jorg K (CEST = GMT+2)]

Bug 1427590 is ancient, already not working from day one when you ported "modern" DevTools to TB 52.

We know that a few things don't work in that area, but something has changed here recently, see regression range, and it's puzzling only server builds are affected and it works in a local build.

Julian, care to take another look?

Comment 5

[Jorg K (CEST = GMT+2)]

Oh, thanks as always, Alice!!!

Comment 6

[Jorg K (CEST = GMT+2)]

Here we have it hiding in the regression range:
883b17280ae1 Brian Grinstead — Bug 1439616 - Enable the new frontend in the Browser Console in nightly builds;r=nchevobbe

Comment 7

[Julian Descottes [:jdescottes]]

Thanks! Based on that, it's probably https://hg.mozilla.org/mozilla-central/rev/883b17280ae1, which enabled the new frontend for the browser console.

The change is not significant but the preference flip changes the code that runs when loading the Browser Console window.

https://searchfox.org/mozilla-central/rev/57bbc1ac58816dc054df242948f3ecf75e12df5f/devtools/client/webconsole/hudservice.js#196-205

You could confirm that by flipping back devtools.browserconsole.new-frontend-enabled to false. 
Now I don't know why one way gives us a window with the expected APIs, and the other doesn't.

Comment 8

[Jorg K (CEST = GMT+2)]

Yes, flipping devtools.browserconsole.new-frontend-enabled back makes it work in the server build as well. I'm still puzzled that only server builds are affected here and it works in local builds either way.

Maybe https://hg.mozilla.org/comm-central/rev/6e1f0a0d00a8 is related??

Comment 9

[Julian Descottes [:jdescottes]]

The preference is only set to true `#if defined(NIGHTLY_BUILD)`. 
I think this is true for a typical local build of Firefox, but maybe not for TB?

Comment 10

[Alice0775 White]

FYI,
forcibly set devtools.browserconsole.new-frontend-enabled = true,

The error massage is different between c-c default build and c-c nightly build.
These builds are built from exactly same change sets.


http://archive.mozilla.org/pub/thunderbird/tinderbox-builds/comm-central-win64/1519038121/
TypeError: onClick is not a function[Learn More]
Frame.js:223:11


http://archive.mozilla.org/pub/thunderbird/tinderbox-builds/comm-central-win64/1519073494/
TypeError: this.gViewSourceUtils is undefined[Learn More]
hudservice.js:400:5

Comment 11

[Jorg K (CEST = GMT+2)]

Hmm, I'm nit sure why the Tinderbox builds of 19-Feb-2018 are relevant here. We know that "view JS source" from the browser/error console doesn't work in TB, that's why we implemented at least a workaround to use an external viewer by setting view_source.editor.external and view_source.editor.path. That was landed in bug 1439021 comment #35 on 2018-03-04.

This bug here is about why that workaround (which is still working today in the "old style" console) is not working in server builds in the "new style" console, but is working in my local build. In fact, in the local build, both links to CSS/JS files open in the external browser and also the [Learn More] links work again.

Comment 12

[Jorg K (CEST = GMT+2)]

Let's look at it further in bug 1454041.