1431060 - Set remote dbg preferences to true when user starts Firefox with --jsdebugger

Status: RESOLVED DUPLICATE of bug 1375280

(DevTools :: General, enhancement, P3)

Description

[Wellington Torrejais da Silva]

User Agent: Mozilla/5.0 (X11; Ubuntu; Linux x86_64; rv:59.0) Gecko/20100101 Firefox/59.0
Build ID: 20180115221039

Steps to reproduce:

Open browser and see:
Could not read chrome manifest 'file:///usr/lib/firefox-trunk/chrome.manifest'. at Browser Console


Actual results:

message: Could not read chrome manifest 'file:///usr/lib/firefox-trunk/chrome.manifest'.


Expected results:

No errors...

Thanks!

Comment 1

[Abe - QA (:Abe_LV)]

Hi Wellington,

I tested this on Ubuntu 16.04 with the latest nightly, but could not manage to reproduce. Here is the screen capture: https://testing-1.tinytake.com/sf/MjI4OTQ3M183MDM0MDY2

Are there specific steps to reproduce this? If this is a regression issue, could you provide the regression range?
Thanks

Comment 2

[Wellington Torrejais da Silva]

(In reply to Abe - QA (:Abe_LV) from comment #1)
> Hi Wellington,
> 
> I tested this on Ubuntu 16.04 with the latest nightly, but could not manage
> to reproduce. Here is the screen capture:
> https://testing-1.tinytake.com/sf/MjI4OTQ3M183MDM0MDY2
> 
> Are there specific steps to reproduce this? If this is a regression issue,
> could you provide the regression range?
> Thanks

Wow, nice reply. Thanks.

I still have this issue: Could not read chrome manifest 'file:///usr/lib/firefox-trunk/chrome.manifest'.

My open command: firefox-trunk --jsconsole --jsdebugger --wait-for-jsdebugger --devtools --no-remote

I have all options checked at "Browser Console" like all of "Net, css, JS..." sub-options.

I'm using Ubuntu(Lubuntu) 18.04. 

See my full log:

Could not read chrome manifest 'file:///usr/lib/firefox-trunk/chrome.manifest'.

Error: Could not run chrome debugger! You need the following prefs to be set to true: devtools.debugger.remote-enabled, devtools.chrome.enabled

Stack trace:
_isRemoteDebuggingEnabled@jar:file:///usr/lib/firefox-trunk/browser/omni.ja!/components/devtools-startup.js:700:21
handleDebuggerFlag@jar:file:///usr/lib/firefox-trunk/browser/omni.ja!/components/devtools-startup.js:709:10
handle@jar:file:///usr/lib/firefox-trunk/browser/omni.ja!/components/devtools-startup.js:227:7
  devtools-startup.js:700
Warning: unrecognized command line flag -wait-for-jsdebugger
  nsBrowserContentHandler.js:756

TypeError: cannot use 'in' operator to search for 'canGoBack' in 'browser'[Learn More]  tabbrowser.xml:2462:1

NS_ERROR_FAILURE: Component returned failure code: 0x80004005 (NS_ERROR_FAILURE) [nsIInterfaceRequestor.getInterface] network-monitor.js:306

Key event not available on some keyboard layouts: key=“r” modifiers=“accel,alt” id=“key_toggleReaderMode”  browser.xul
Key event not available on some keyboard layouts: key=“i” modifiers=“accel,alt,shift” id=“key_browserToolbox”  browser.xul


Thanks again!

Comment 3

[Abe - QA (:Abe_LV)]

This is reproducible on Ubuntu 16.04 amd64 with latest nightly using comment 2. This is not reproducible on Windows-10.

This is the log:

Error: Could not run chrome debugger! You need the following prefs to be set to true: devtools.debugger.remote-enabled, devtools.chrome.enabled
Stack trace:
_isRemoteDebuggingEnabled@jar:file:///home/svuser/Desktop/64bitsNightly/browser/omni.ja!/components/devtools-startup.js:700:21
handleDebuggerFlag@jar:file:///home/svuser/Desktop/64bitsNightly/browser/omni.ja!/components/devtools-startup.js:709:10
handle@jar:file:///home/svuser/Desktop/64bitsNightly/browser/omni.ja!/components/devtools-startup.js:227:7

Comment 4

[Julian Descottes [:jdescottes]]

Moving this to Developer Tools, thanks for logging!

Did you try setting the preferences as explained at https://developer.mozilla.org/en-US/docs/Tools/Browser_Toolbox#Enabling_the_Browser_Toolbox ? This is the same as what the error message hints at "You need the following prefs to be set to true: devtools.debugger.remote-enabled, devtools.chrome.enabled".

I quickly tried the latest Nightly on linux, and I only have the issue if the preferences are not set correctly. Overall maybe we should flip the preferences automatically if those command line arguments are passed.

Comment 5

[Wellington Torrejais da Silva]

(In reply to Julian Descottes [:jdescottes][:julian] from comment #4)
> Moving this to Developer Tools, thanks for logging!
> 
> Did you try setting the preferences as explained at
> https://developer.mozilla.org/en-US/docs/Tools/
> Browser_Toolbox#Enabling_the_Browser_Toolbox ? This is the same as what the
> error message hints at "You need the following prefs to be set to true:
> devtools.debugger.remote-enabled, devtools.chrome.enabled".
> 
> I quickly tried the latest Nightly on linux, and I only have the issue if
> the preferences are not set correctly. Overall maybe we should flip the
> preferences automatically if those command line arguments are passed.

Nice, I think set this by default It's a good idea.

The first error don't occurred after settings change, but now I see this error:

01:25:38.670 error occurred while processing 'sources: TypeError: can't access dead object
Stack: createNonSourceMappedActor@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/TabSources.js:313:1
createSourceActors/<@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/TabSources.js:401:19
process@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:922:23
walkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:806:7
Promise*scheduleWalkerLoop@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:739:11
schedulePromise@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:770:7
Promise.prototype.then@resource://gre/modules/Promise.jsm -> resource://gre/modules/Promise-backend.js:455:5
createSourceActors@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/utils/TabSources.js:400:12
_discoverSources/<@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/script.js:1349:14
_discoverSources@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/script.js:1348:16
onSources@resource://devtools/shared/base-loader.js -> resource://devtools/server/actors/script.js:1354:12
onPacket@resource://devtools/shared/base-loader.js -> resource://devtools/server/main.js:1788:15
_onJSONObjectReady/<@resource://devtools/shared/base-loader.js -> resource://devtools/shared/transport/transport.js:483:11
exports.makeInfallible/<@resource://devtools/shared/base-loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:109:14
exports.makeInfallible/<@resource://devtools/shared/base-loader.js -> resource://devtools/shared/ThreadSafeDevToolsUtils.js:109:14
Line: 313, column: 1 1 main.js:1651
	_unknownError resource://devtools/server/main.js:1651:5
	_queueResponse/responsePromise< resource://devtools/server/main.js:1669:25
	reject resource://devtools/shared/deprecated-sync-thenables.js:50:41
	then resource://devtools/shared/deprecated-sync-thenables.js:26:51
	resolve resource://devtools/shared/deprecated-sync-thenables.js:77:11
	reject resource://devtools/shared/deprecated-sync-thenables.js:51:16
	process resource://gre/modules/Promise-backend.js:925:21
	walkerLoop resource://gre/modules/Promise-backend.js:806:7
	bound walkerLoop self-hosted:947:17
	bound walkerLoop self-hosted:947:17


Thanks...

Comment 6

[Julian Descottes [:jdescottes]]

Can't reproduce, might be related to one of your tabs or something in your profile?

We need more information to investigate. Are you testing a specific website? Are you sure you need --jsconsole --jsdebugger --wait-for-jsdebugger --devtools. These arguments are meant to debug Firefox itself. Can you share detailed steps we could follow to reproduce your issue?

Thanks.

Comment 7

[Wellington Torrejais da Silva]

(In reply to Julian Descottes [:jdescottes][:julian] from comment #6)
> Can't reproduce, might be related to one of your tabs or something in your
> profile?
> 
> We need more information to investigate. Are you testing a specific website?
> Are you sure you need --jsconsole --jsdebugger --wait-for-jsdebugger
> --devtools. These arguments are meant to debug Firefox itself. Can you share
> detailed steps we could follow to reproduce your issue?
> 
> Thanks.

This flags are very nice to debug websites and It's useful to understand browser strange things.
I don't associate to specific webpage  or tab., yet.
And I frequently use clean profiles.

By the way, I will to do observation with more details and will add here as soon as possible.

Thanks!

Comment 8

[Julian Descottes [:jdescottes]]

The goal here is to set the remote debugging preferences [1] to true if the user passes either --jsdebugger or --wait-for-jsdebugger when starting Firefox. Today we simply check the preferences and log an error if they are not set.

[1] "devtools.debugger.remote-enabled" and "devtools.chrome.enabled" 

Ryan, do you think we should be concerned about security for such a change?

Comment 9

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

(In reply to Julian Descottes [:jdescottes][:julian] from comment #8)
> The goal here is to set the remote debugging preferences [1] to true if the
> user passes either --jsdebugger or --wait-for-jsdebugger when starting
> Firefox. Today we simply check the preferences and log an error if they are
> not set.
> 
> [1] "devtools.debugger.remote-enabled" and "devtools.chrome.enabled" 
> 
> Ryan, do you think we should be concerned about security for such a change?

Hmm... choosing the right balance of security vs. UX like this is usually a bit tricky.  In this case, we have these disabled prefs so that regular users aren't affected by security issues that would arise with a DevTools server listening for connections and allowing chrome access.  The security impact of such a server is at least limited to only software running on the user's machine since the server port only binds to the local interface.

I am unsure whether people who enable the corresponding checkboxes in Toolbox Options actually understand the security impact of those settings...  More likely, they are just following a checklist to use some feature.  It's hard to say without more user data.

Since flags like `--jsdebugger` express a clear user intent to access these debugging features, it seems safe to me to try to get the two prefs out of the way.  It seems a bit better for security though if we could find a way to only flip the state of the prefs (or at least the code paths affected by them) for the current session when using CLI flags like `--jsdebugger`, so then the security impact only applies for the session where the flag was given.

If it turns out to be too complex to make it apply to the current session only, then just setting the prefs seems like something we could probably live with given the UX improvement for people who want to debug.

Comment 10

[Brian Grinstead [:bgrins]]

Is this still an issue for your use case? Based on Comment 2 it looks like you may be using a local build, and we've now enabled chrome and remote debugging for local builds by default (https://groups.google.com/d/msg/firefox-dev/678mrnS6120/KXcP18ZUCAAJ / Bug 1375280).

Comment 11

[Brian Grinstead [:bgrins]]

I'd generally like to avoid setting these prefs (especially permanently) as a result of a command line flag passed to startup once. It's not clear to me how frequently the BT is used in non-local builds - do we have data on that? If this is a common/important use case then the UX improvement could be worth the trade off. We should check with the security team before making the change.

Comment 12

[Julian Descottes [:jdescottes]]

Thanks for the feedback Ryan & Brian. I agree that flipping the preferences permanently might be dangerous if you are doing this on a regular build of Firefox, that's a good point.

And as Brian said, Bug 1375280 fixes this use case for local builds anyway. In favor of closing as duplicate of Bug 1375280, will give it a few days for the logger to raise concerns.