@SunriseFox we have a couple of questions to get a better picture of the issue (and how to reproduce it):

• is the Firefox for android instance already running while you are pressing Ctrl-C?
• which windows shell are you using? (e.g. cmd or powershell)
• are you using any third party terminal application or the stardard one?

1. Yes.
2. Powershell.
3. The standard one.

@SunriseFox Can I start work on this?

Can I start work on this?

CS-Aditya-Rawat This bug requires some more investigation to determine more details about the underlying issue (and based on that the kind of changes we would prefer to fix it as its first step), and so if you are looking for a good-first-bug as a initial contribution then this one may not be a good "entry point" (at least not yet).

If a "good first bug" is what you are looking for, you may take a look to the ones not yet assigned to a contributor (or a PR recently open and linked to the issue) from this list:

• https://addons-pm.herokuapp.com/contrib/good-first-bugs/?dir=desc&sort=updatedAt

Or one from the "contrib:welcome" list (but be aware that the older issues in the "contrib:welcome" list may not be relevant anymore but not closed yet, and they may require a bit more experience than the one marked as "good first bug"):

• https://addons-pm.herokuapp.com/contrib/contrib-welcome/?dir=desc&sort=updatedAt

Hello:

I've investigated this issue, and the problem arises in this finally block

 try {
      // Got a debugger socket file to connect.
      this.selectedRDPSocketFile = (
        await adbUtils.discoverRDPUnixSocket(
          selectedAdbDevice, selectedFirefoxApk, {
            maxDiscoveryTime: unixSocketDiscoveryMaxTime,
            retryInterval: unixSocketDiscoveryRetryInterval,
          }
        )
      );
    } finally {
      if (isTTY(stdin)) {
        stdin.removeListener('keypress', handleCtrlC);
      }
    }

Removing the finally block (or the whole try...finally block leaving the try code for that matter) fixes the issue.
Honestly, I don't understand why is that finally there to begin with as you are always removing the listener regardless, maybe it was meant to be a catch?

@rpl can you assign me to this? This would be my first contribution but I think it's a pretty easy fix

@luskaner feel free to submit a PR with "Fixes #1699" in the description, we'll assign you then

@willdurand thanks will do

Further investigating this happens in either of the following two conditions (in run):

• Automatic reloading is disabled.
• Waiting to launch the activity on Android. For example: this occurs undefinitely when my device when it is locked.

@willdurand PR linked and ready ;)

(I didn't forget about this PR, just have no time at the moment, sorry - I'll get back to it ASAP)