(used: Firefox 34.0.5 on 64 bit Linux, but that likely happens everywhere) In short: Firefox should just not pull in a addon which I never wanted and IF, then it should provide info about the addon - why it is there, who put it there... if I find it in my addon list. This adbhelper addon (0.7.2) accidentally caused some trouble in the past (see bug 1113103). When I first experienced the caused trouble, it was really hard to get some info about what was why going on. If you accidentally find this addon in your addon list (as I did), it was hard to get to know why it is there, What is does, who it programmed, ... There is only a link to the github repository included - which has a readme (if you find it) which is not very helpful. A fresh profile does not have this extension, but it got pulled in as soon I started Firefox' WebIDE - clearly visible (along with many WARN about exceptions). In my usual working profile I do not remember having started the WebIDE when the addon was downloaded. The same for a friend. There the addon was downloaded (according to file system dates) roughly at the same date. I did never used the WebIDE, *but* I tried it out once, because I was looking what toys are in Firefox' menus. Same for my friend. Apparently this is THE info page about this addon https://developer.mozilla.org/en-US/Firefox_OS/Using_the_App_Manager So this one should be provided in the links which the addon has in the addon list. There should be info telling you that the addon was likely automatically installed because you started the WebIDE once. There should be info how to permanently remove it. And in addition I would say that you should ask the user if he wants to have this addon at all BEFORE you automatically download and install it. This is the stable firefox version, not a nightly or testers' version

Confirming and raising severity. I just encountered this myself, after opening WebIDE and immediately closing it. That alone should not cause the silent installation of extensions, especially not an extension which statically downloads and runs adb in the background on every firefox startup. I only noticed this because I happened to run firefox from a terminal and saw this: * daemon not running. starting it now on port 5037 * * daemon started successfully * Prompting to install these extensions would be OK. Silently installing them, and then silently running adb on *every* firefox startup, is definitely not OK. This needs to be disabled and moved behind a prompt of some kind, ideally in a point release of Firefox 38. Furthermore, for the benefit of users who may have these extensions installed when they don't need them (which among other things will slow down Firefox startup, and interfere with a user-installed adb if any), we need some way to clean up this situation.

WebIDE's main use case today is to connect to devices, and for this to function, the ADB Helper addon is downloaded when it is first opened. The fact that it is an add-on is really just an implementation detail. It could instead be packaged with Firefox or installed through some other mechanism. Packaging it as an add-on allows Firefox downloads to remain smaller since it's only installed for WebIDE users. The add-on is auto-installed on WebIDE open to simplify the process of connecting to a device for the first time. Only one attempt is made to auto-install the add-on. You can remove it from the add-on manager just like any other, if you wish. As for the fact that it starts up ADB on every Firefox start up, I agree that's something to fix. Bug 1026945 is filed for this. You mention that it interferes with a user-installed ADB. If you've see actual issues like this, please file a separate bug for them. The helper add-on is intended to play nicely with other usages of ADB outside of Firefox, so it should not interfere.

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #2) > WebIDE's main use case today is to connect to devices, and for this to function, the ADB Helper addon is downloaded when it is first opened. That might have been the case in the past (I presume), but nowadays you have the choice between a remote firefox, an android device, an ios device and a simulator. Which means you don't need adb for 3 out of 4 possibilities.

and chrome desktop, which makes it 5 possibilities, although ios device and chrome desktop need the tools adapters addon. Not autoinstalling the adb helper makes the remote runtime menu show a "Install ADB Helper" item, like there is a "Install simulator" item. Interestingly, there is no "Install something" item when the tools adapters addon is not installed.

(In reply to Mike Hommey [:glandium] from comment #4) > Not autoinstalling the adb > helper makes the remote runtime menu show a "Install ADB Helper" item, like > there is a "Install simulator" item. That sounds like the ideal behavior. (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #2) > WebIDE's main use case today is to connect to devices, and for this to > function, the ADB Helper addon is downloaded when it is first opened. The > fact that it is an add-on is really just an implementation detail. It could > instead be packaged with Firefox or installed through some other mechanism. > Packaging it as an add-on allows Firefox downloads to remain smaller since > it's only installed for WebIDE users. "opened the WebIDE once" does not mean "user of WebIDE". Having a prompt to install the ADB helper doesn't seem exceptionally painful for WebIDE users. (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #2) > You mention that it interferes with a user-installed ADB. If you've see > actual issues like this, please file a separate bug for them. The helper > add-on is intended to play nicely with other usages of ADB outside of > Firefox, so it should not interfere. ADB is well-known for not coexisting with other instances of ADB; it writes to files with fixed names, opens sockets at fixed locations, and otherwise assumes it's the only ADB on the system.

(In reply to Mike Hommey [:glandium] from comment #3) > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #2) > > WebIDE's main use case today is to connect to devices, and for this to function, the ADB Helper addon is downloaded when it is first opened. > > That might have been the case in the past (I presume), but nowadays you have > the choice between a remote firefox, an android device, an ios device and a > simulator. Which means you don't need adb for 3 out of 4 possibilities. Right, the ADB Helper addon is used for: * Firefox OS * Firefox for Android It's not needed for: * Chrome * Safari / iOS * Firefox OS Simulators My guess is that Firefox OS devices / simulators are the main use cases today. However, I can't be sure at the moment, as we don't have good data on this. In bug 1159043, I'm adding more telemetry to get a better idea of what users connect to. For Firefox OS devices, we've recently added WiFi debugging, which does not need ADB. However, it will take some time for supported device to reach the market. If WiFi debugging becomes the typical connection method, then I would be more comfortable with turning off the auto-install of ADB Helper. (In reply to Mike Hommey [:glandium] from comment #4) > and chrome desktop, which makes it 5 possibilities, although ios device and > chrome desktop need the tools adapters addon. Not autoinstalling the adb > helper makes the remote runtime menu show a "Install ADB Helper" item, like > there is a "Install simulator" item. Interestingly, there is no "Install > something" item when the tools adapters addon is not installed. Yes, that's a bit of a UX quirk I guess. For Valence / tools adapters, we also auto-install on WebIDE open, but there's no runtime menu prompt to install at the moment. This is similar to what's reported in bug 1161845.

(In reply to Josh Triplett from comment #5) > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #2) > > You mention that it interferes with a user-installed ADB. If you've see > > actual issues like this, please file a separate bug for them. The helper > > add-on is intended to play nicely with other usages of ADB outside of > > Firefox, so it should not interfere. > > ADB is well-known for not coexisting with other instances of ADB; it writes > to files with fixed names, opens sockets at fixed locations, and otherwise > assumes it's the only ADB on the system. But that's not true for the ADB Helper add-on: if you already started ADB on your system, the add-on will connect to that instance, instead of starting it's own. This is an example of what I mean by playing nice with other usages.

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #7) > (In reply to Josh Triplett from comment #5) > > (In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #2) > > > You mention that it interferes with a user-installed ADB. If you've see > > > actual issues like this, please file a separate bug for them. The helper > > > add-on is intended to play nicely with other usages of ADB outside of > > > Firefox, so it should not interfere. > > > > ADB is well-known for not coexisting with other instances of ADB; it writes > > to files with fixed names, opens sockets at fixed locations, and otherwise > > assumes it's the only ADB on the system. > > But that's not true for the ADB Helper add-on: if you already started ADB on > your system, the add-on will connect to that instance, instead of starting > it's own. This is an example of what I mean by playing nice with other > usages. That's assuming your own is compatible with Firefox's. And for that matter, if Firefox's starts first, it'll block a user's ADB (and potentially associated scripts) from running.

(In reply to Josh Triplett from comment #8) > That's assuming your own is compatible with Firefox's. And for that matter, > if Firefox's starts first, it'll block a user's ADB (and potentially > associated scripts) from running. I have not experienced it blocking ADB in the past. The ADB client (the one outside of the add-on, from the Android SDK) checks the version of the server if it's already running. If it's not the version it expects, it kills the server and starts one it does like. That should allow scripts and such to proceed. We're getting off the topic of the add-on's installation itself here. If you have a specific case with reproducible steps where the ADB Helper add-on is blocking some other ADB workflow, please file a separate bug for it so the add-on can be fixed to get out of the way, as it intends to.

(In reply to J. Ryan Stinnett [:jryans] (use ni?) from comment #9) > We're getting off the topic of the add-on's installation itself here. If > you have a specific case with reproducible steps where the ADB Helper add-on > is blocking some other ADB workflow, please file a separate bug for it so > the add-on can be fixed to get out of the way, as it intends to. Agreed; I'm not particularly concerned with the exact behavior of ADB Helper, as long as it 1) isn't installed silently just from opening WebIDE, and 2) doesn't launch ADB on Firefox startup.

About:debugging bug triage. Filter on TRIAGE-JD201705 Temporarily setting P3 to bugs migrated from webide to cleanup the triage for about:debugging.