1071473 - (rm-connect) [meta] Remove Connect page

Status: RESOLVED DUPLICATE of bug 1539462

(DevTools :: Framework, task)

Description

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

WebIDE now supports:

* Connecting to a remote runtime via host and port
* Listing and debugging remote tabs
* Debugging the remote chrome / main process

It does not yet support:

* Debugging remote add-ons

I don't see much value in having two ways to do these things, so let's remove the Connect page once everything is available in WebIDE.

Comment 1

[Philipp Kewisch [:Fallen] [:📆][:🧩]]

Note that the webide has a lot more clicks just to get debugging for a remote main processes set up:

WebIDE:

1. Shift + F8 to open webide
2. Select Runtime dropdown
3. Remote runtime
4. Ok on popup to connect
5. App dropdown
6. Main process
7. Debugger button
8. Click+Drag to expand toolbox

Connect Page:

1. Click on bookmark in bookmarks toolbar
2. Click on connect button
3. Click on main process

Before you get rid of that page I'd appreciate a quicker alternative, even if this ends up being fixing bug 933720 so I can add an item to Thunderbird that would trigger Firefox connecting to the running Thunderbird instance.

Comment 2

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

(In reply to Philipp Kewisch [:Fallen] from comment #1)
> Note that the webide has a lot more clicks just to get debugging for a
> remote main processes set up:
> 
> WebIDE:
> 
> 1. Shift + F8 to open webide
> 2. Select Runtime dropdown
> 3. Remote runtime
> 4. Ok on popup to connect
> 5. App dropdown
> 6. Main process
> 7. Debugger button
> 8. Click+Drag to expand toolbox
> 
> Connect Page:
> 
> 1. Click on bookmark in bookmarks toolbar
> 2. Click on connect button
> 3. Click on main process
> 
> Before you get rid of that page I'd appreciate a quicker alternative, even
> if this ends up being fixing bug 933720 so I can add an item to Thunderbird
> that would trigger Firefox connecting to the running Thunderbird instance.

Yep, you're right.  I never realized just how much people dislike extra clicks before working on this project...  (This has been mentioned in other bugs about WebIDE as well.) :)

We're actively working to reduce this number in various ways.  For example, step 7 is no longer needed as we auto-open the toolbox for non-editable projects like the main process.

Also, we're working on remembering and automate selecting the most recent project (bug 1055666), so that would eliminate steps 4 and 5.

We recently added some support to remember and automate selecting the most recent runtime, but that was not done for remote runtimes, so I filed bug 1071488 for it.  With that ability, steps 2, 3, and 4 can be eliminated.

So, pretty soon we'll have it down to essentially "open WebIDE" as long as the remote and project you want are the ones you used last time.

I am happy to consider any other ideas to improve the UX as well, so please file if you have them.

Comment 3

[Alexandre Poirot [:ochameau]]

Connect screen is currently broken with the following exception:
*************************
A coding exception was thrown and uncaught in a Task.

Full message: TypeError: DebuggerSocket is undefined
Full stack: DebuggerClient.socketConnect@resource://gre/modules/devtools/dbg-client.jsm:387:3
submit<@chrome://browser/content/devtools/connect.js:71:25
TaskImpl_run@resource://gre/modules/Task.jsm:314:40
TaskImpl@resource://gre/modules/Task.jsm:275:3
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:249:14
onDOMReady/<@chrome://browser/content/devtools/connect.js:44:5

With some more debugging we can find the original issue:
[Exception... "Component returned failure code: 0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE) [nsIJSCID.getService]"  nsresult: "0x80570016 (NS_ERROR_XPC_GS_RETURNED_FAILURE)"  location: "JS frame :: resource://gre/modules/commonjs/toolkit/loader.js -> resource://gre/modules/devtools/security/socket.js :: <TOP_LEVEL> :: line 12"  data: no] - @undefined:12:undefined
@resource://gre/modules/devtools/security/socket.js:12:0
@resource://gre/modules/devtools/dbg-client.jsm:85:27
defineLazyGetter/<.get@resource://gre/modules/devtools/DevToolsUtils.js:392:30
DebuggerClient.socketConnect@resource://gre/modules/devtools/dbg-client.jsm:387:2
submit<@chrome://browser/content/devtools/connect.js:71:24
TaskImpl_run@resource://gre/modules/Task.jsm:314:39
TaskImpl@resource://gre/modules/Task.jsm:275:2
createAsyncFunction/asyncFunction@resource://gre/modules/Task.jsm:249:13
onDOMReady/<@chrome://browser/content/devtools/connect.js:44:4


http://mxr.mozilla.org/mozilla-central/source/toolkit/devtools/security/socket.js#12
  Cc["@mozilla.org/psm;1"].getService(Ci.nsISupports);
psm component throws in the connect page codepath, no idea why it doesn't throw in webide codepath.

Comment 4

[Alexandre Poirot [:ochameau]]

Oh right, nevermind, it was throwing because I was trying to run the connect page OOP. But it doesn't support e10s!

Comment 5

[Alexandre Poirot [:ochameau]]

4 years... and the connect page is still here and we keep maintaining it, in addition to WebIDE, the old and the new about:debugging!

The new about:debugging is starting to get remote debugging capabilities... may be we can remove it now?

It doesn't support debugging processes, so it doesn't help debugging xpcshell tests, but WebIDE does.
There is bug 1488513 to implement processes support in the new about:debugging (no clear timeline for this one).
And bug 1495380 to enable remote addons debugging (planned M2 release, so 65).

Luca, is this still being used for debugging remote add-ons?

Comment 6

[Luca Greco [:rpl] [:luca] [:lgreco]]

(In reply to Alexandre Poirot [:ochameau] from comment #5)
> 4 years... and the connect page is still here and we keep maintaining it, in
> addition to WebIDE, the old and the new about:debugging!
> 
> The new about:debugging is starting to get remote debugging capabilities...
> may be we can remove it now?
> 
> It doesn't support debugging processes, so it doesn't help debugging
> xpcshell tests, but WebIDE does.
> There is bug 1488513 to implement processes support in the new
> about:debugging (no clear timeline for this one).
> And bug 1495380 to enable remote addons debugging (planned M2 release, so
> 65).
> 
> Luca, is this still being used for debugging remote add-ons?

Personally I often use the WebIDE to connect remotely to a Firefox for Android instance
and debug remotely add-ons running there,
and the WebIDE is also what we currently suggest to addon developers in the related MDN doc page:

- https://developer.mozilla.org/en-US/docs/Mozilla/Add-ons/WebExtensions/Developing_WebExtensions_for_Firefox_for_Android#Debug_your_extension

Starting to remove the connect page sounds reasonable to me too.

Comment 7

[Alexandre Poirot [:ochameau]]

This MDN page documents how to debug a content script, which you may do via the Main process or tab toolbox,
but it doesn't allow you to have the same "web extension toolbox" you have on desktop.
I was wondering if you were able to have this toolbox from the connect page for android add-ons?
Did you tried? Is it broken?

In the connect page we do list addons and allow opening toolboxes for them, whereas we don't list addons on WebIDE.

Comment 8

[Alexandre Poirot [:ochameau]]

Attachment: Connect page with remote add-ons

The connect page still works for remote add-ons.

Is anyone still using that??

It requires to do a manual call to `adb forward` or execute `adb forward --list` to know to which port to connect.
Also, I was wondering what was broken on new about:debugging regarding remote add-ons? The connect page is having a trivial implementation and seems to work fine at first sight.