Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add argument to specify firefox remote debugger port #2891

Open
alicedb2 opened this issue Sep 25, 2023 · 1 comment
Open

Add argument to specify firefox remote debugger port #2891

alicedb2 opened this issue Sep 25, 2023 · 1 comment

Comments

@alicedb2
Copy link

alicedb2 commented Sep 25, 2023

Is this a feature request or a bug?

Feature request

What is the current behavior?

The firefox-desktop launcher relies on findFreeTcpPort() and passes it to firefox-bin with --start-debugger-server [some_free_TCP_port]. Trying to override this behavior using web-ext run --firefox --args="--start-debugger-server [my_TCP_port] fails because firefox ignores the second occurrence of --start-debugger-server in the command line. Using --pref=devtools.debugger.remote-port=[my_TCP_port] doesn't work either because command line arguments take precedence.

What is the expected or desired behavior?

The main motivation behind allowing the user to specify the remote debugger port is to make it easier to use web-ext together with the VS code "Debugger for Firefox" extension. Right now one has to use something like netstat or lsof to find out which remote debugger port web-ext launched firefox with, then go and modify the port option in .vscode/launch.json to allow "Debugger for Firefox" to correctly attach to the remote debug console. This has to be done after each restart of web-ext.

@rpl
Copy link
Member

rpl commented Sep 28, 2023

One other possible approach to get the port we choose internally may be to use web-ext as a nodejs library and programmatically retrieve the port through that, using web-ext as library is not fully supported use case but we have a small set of test cases to ensure we don't break it without noticing, but most of the details need to be determined by looking to how web-ext uses the internals that are also exported when used as a library.

Alternatively we are open to consider introducing an explicit option, if the proposed approach looks clean, and so we are also marking this issue as contrib welcome.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants