1085446 - Javascript sources loaded in chrome URIs are not visible

Status: RESOLVED FIXED

(DevTools :: Debugger, defect)

Description

[Mindaugas <LA-MJ>]

I am an addon maintainer and I use chrome://my_addon/content/preferences.html page for add-on preferences.

The page loads some javascript sources via <script> tags but they are not visible in web console's debugger:
http://i.imgur.com/qIj93E8.png

However, that is 'only' a visual problem. 
Adding 'debugger;' somewhere in the code and allowing the execution to reach it results in a paused state with file/line/scope/stack information displayed (and functional stepping through buttons) but still without actual sources:
http://i.imgur.com/76ocYr4.png

I'd like to have proper debugging with visual sources and ability to add temporary breakpoints for chrome URI scripts.

This issue still exists in current nightly and seems to have been around forever.

Comment 1

[Nick Fitzgerald [:fitzgen] [⏰PST; UTC-8]]

I think you want to be using the browser toolbox: https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox

Comment 2

[Mindaugas <LA-MJ>]

Browser toolbox does not react to these scripts. That's the problem. They are not global chrome scripts.
E. g. they are executed in remote tabs with e10s (see bug 1085424). 

Like I described web console actually allows you to step through the code(!) (albeit blindly) so the browser toolbox will not help here.

Comment 3

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

I believe this is related to same issue we're attempting to resolve in bug 1060093 by offering a toolbox connected to the content process.

Depending on that issue for now to check again once it's resolved.

Comment 4

[:Gijs (he/him)]

This also affects e.g. about:support and about:preferences. It'd be nice if this could be fixed, perhaps by checking the same "allow chrome/addon debugging" bool pref as the browser console's input field works off.

Comment 5

[Brian Grinstead [:bgrins]]

(In reply to :Gijs Kruitbosch from comment #4)
> This also affects e.g. about:support and about:preferences. It'd be nice if
> this could be fixed, perhaps by checking the same "allow chrome/addon
> debugging" bool pref as the browser console's input field works off.

That seems reasonable

Comment 6

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

Something tell me this block[1] is "suspicious":

    // Ignore XBL bindings for content debugging.
    if (url && url.indexOf("chrome://") == 0) {
      return false;
    }
    // Ignore about:* pages for content debugging.
    if (url && url.indexOf("about:") == 0) {
      return false;
    }

[1]: http://hg.mozilla.org/integration/fx-team/file/2f2f5bddfa60/toolkit/devtools/server/actors/script.js#l2122

Comment 7

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

The about check was added in bug 760882, and the chrome check in bug 767389.

It appears they were both added at the time because chrome / about source would sometimes appear in the debugger on regular pages, which would be confusing.  However, I can't reproduce the original issues in those bugs anymore.  I'll attach a patch to remove these checks, but hopefully Panos can say for sure if this is the right path to take.

By removing these checks, it's so much easier to debug chrome / about pages!

For the original reporter, can you attach your add-on so I can test if this fixes your use case too?

Comment 8

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

Attachment: MozReview Request: bz://1085446/jryans

Comment 9

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

/r/1053 - Bug 1085446 - Allow chrome and about sources in tabs. r=past

Pull down this commit:

hg pull review -r d3a8c9c47057614b3bf88c4a4bf0b5b44ec77375

Comment 10

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

Try: https://treeherder.mozilla.org/#/jobs?repo=try&revision=1958be0c86c9

Comment 11

[Mindaugas <LA-MJ>]

Attachment: addon test case

Adding a test case:

1) visit chrome://chrome_tester/content/preferences.html
2) open web console
3) open debugger tab
4) reload the page

execution should be paused at this point

Comment 12

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

https://reviewboard.mozilla.org/r/1051/#review629

It used to be impossible to debug chrome pages with the content toolbox, because in that case there are both debugger and debuggee frames on the stack. After shu fixed bug 716647 it appears that this is now working, so hurray!

Comment 14

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

(In reply to 4mr.minj from comment #11)
> Created attachment 8529777 [details]
> addon test case
> 
> Adding a test case:
> 
> 1) visit chrome://chrome_tester/content/preferences.html
> 2) open web console
> 3) open debugger tab
> 4) reload the page
> 
> execution should be paused at this point

Great, the patch indeed fixes this use case!

Comment 15

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

https://hg.mozilla.org/integration/fx-team/rev/332134580365

Comment 16

[Carsten Book [:Tomcat]]

https://hg.mozilla.org/mozilla-central/rev/332134580365

Comment 17

[Sebastian Zartner [:sebo]]

Release Note Request (optional, but appreciated)
[Why is this notable]: Important for add-on developers using the DevTools to debug them
[Suggested wording]: JavaScript sources of chrome URIs visible in Debugger panel
[Links (documentation, blog post, etc)]: https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox, https://developer.mozilla.org/en-US/docs/Tools/Debugger

Sebastian

Comment 18

[Mindaugas <LA-MJ>]

I confirm that 2014-12-04 nightly is working as expected.
Thank you for your efforts.

Comment 20

[Lawrence Mandel [:lmandel] (use needinfo)]

I'm trying to figure out if there is a different way to relnote this change. Based on the links provided, is the Browser Toolbox new? Is it correct to say "Debugger panel support for debugging Chrome"?

Comment 21

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

(In reply to Lawrence Mandel [:lmandel] (use needinfo) from comment #20)
> I'm trying to figure out if there is a different way to relnote this change.
> Based on the links provided, is the Browser Toolbox new?

No, the Browser Toolbox is not new, and this feature does not affect the Browser Toolbox.  (It was already able to reach most of these pages, but is less convenient that the in-tab toolbox.)
 
> Is it correct to say "Debugger panel support for debugging Chrome"?

The change here is that chrome:// and about:// pages for a tab are now visible in the regular, in-tab toolbox's Debugger.

"Chrome" with a _C_ I think is confusing here, especially when there are other projects like Valence that are about connecting to Google Chrome.

So how about "Debugger panel support for chrome:// and about:// URIs"

Comment 22

[Lawrence Mandel [:lmandel] (use needinfo)]

wfm thanks.

Comment 23

[Will Bamberg [:wbamberg]]

I've added notes in these 2 pages:
https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox#Debugging_chrome.3A_and_about.3A_pages
https://developer.mozilla.org/en-US/Add-ons/Add-on_Debugger#Debugging_chrome.3A_and_about.3A_pages

... since they seem like the most likely places that people interested in doing this might look. Does this cover it?

Comment 24

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

Thanks, looks good to me!

Comment 26

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

Attachment: MozReview Request: Bug 1085446 - Allow chrome and about sources in tabs. r=past