1570693 - Make --jsdebugger and --wait-for-jsdebugger work in GeckoView consuming Apps

Status: NEW

(DevTools :: General, enhancement, P2)

Description

[Nick Alexander :nalexander [he/him]]

Right now, the "devtools startup" pieces that handle these flags are protected by MOZ_DEVTOOLS, which is server (and not all) for GeckoView (and Fennec). See https://searchfox.org/mozilla-central/rev/b38e3beb658b80e1ed03e0fdf64d225bd4a40327/devtools/startup/components.conf#9.

Can we make the devtools useful for (some) startup debugging in GeckoView out of the box?

Comment 1

[Nick Alexander :nalexander [he/him]]

This might help debugging system add-on issues in Bug 1570690, for example. Panos, can you comment on what this would take, or redirect as appropriate? Thanks!

Comment 2

[Panos Astithas (he/him) [:past] (please ni?)]

Sorry for the delay, I was on PTO. I think this is Core Tools team's turf.

Comment 3

[Soledad Penades [:sole] [:spenades]]

Hello Nick, and thanks Panos for forwarding!

Most of the people who know the most about devtools startup are on holidays right now, but maybe we can do a bit of prep work by helping me understand what type of usefulness you are thinking of.

I'm not familiar with how is GeckoView consumed in apps, so bear with me:

I suppose this requires implementing some 'command line' arguments to start GeckoView with --jsdebugger and --wait-for-jsdebugger "on", but I wonder if this is on the app, on Gecko itself or on the GeckoView "wrapper" side.

Are they implemented at all right now? Can you start a GeckoView app and ask it to start the server and wait for a devtools connection?

From the DevTools side of things I know we have to be careful about when we start the server so we don't slow down the rest of the browser. If GeckoView startup is fundamentally different from a desktop Gecko and you want to be able to inspect data you can't right now, I wonder if it would be possible/acceptable to have an 'extra early start' or something that lets us start super early (not sure when this could be) and pause things as soon as it's possible too. I suspect we cannot pause Java execution, though :-)

[Possibly silly question] Can I double check that you don't want to channel ADB logcat messages towards the devtools console? You are still able to pull those messages from GeckoView using standard Android debugging tools, I hope.

Before we try to guess what would be an improvement for you or I keep having somewhat extravagant ideas, do you have any specific requests or thoughts about what would be an improvement for you compared to the current situation?

FYI people will start coming back next week, so they can assess the feasibility of whatever we discuss here then.

I hope that helps :-)

Comment 4

[Nick Alexander :nalexander [he/him]]

(In reply to Soledad Penades [:sole] [:spenades] from comment #3)

Hello Nick, and thanks Panos for forwarding!

Most of the people who know the most about devtools startup are on holidays right now, but maybe we can do a bit of prep work by helping me understand what type of usefulness you are thinking of.

I'm not familiar with how is GeckoView consumed in apps, so bear with me:

I suppose this requires implementing some 'command line' arguments to start GeckoView with --jsdebugger and --wait-for-jsdebugger "on", but I wonder if this is on the app, on Gecko itself or on the GeckoView "wrapper" side.

These would be command line arguments that GV recognizes (it would get them via its configuration file, see https://mozilla.github.io/geckoview/consumer/docs/automation) and that are known at Gecko startup time. The command line argument piece, at least, is essentially the same as it is for Desktop.

Are they implemented at all right now? Can you start a GeckoView app and ask it to start the server and wait for a devtools connection?

Yes, you can. I imagine that's what the server value (and not all value) I linked to in #c0 is about. So you can happily use about:debugging to target any GeckoView-consuming Android App (that enables Remote Debugging).

From the DevTools side of things I know we have to be careful about when we start the server so we don't slow down the rest of the browser. If GeckoView startup is fundamentally different from a desktop Gecko and you want to be able to inspect data you can't right now, I wonder if it would be possible/acceptable to have an 'extra early start' or something that lets us start super early (not sure when this could be) and pause things as soon as it's possible too. I suspect we cannot pause Java execution, though :-)

I recognize the delicate "only start when really needed" dance that devtools must dance. GV startup is not fundamentally different from Desktop; at some point, we ask Gecko to start, and at some time (very early!) we can turn on the profiler, etc. I'd like to be able to connect the JS debugger early too.

In fact, you could pause kinda-sorta pause Java, but that's not what we want. In the same way that devtools-on-Desktop will spin the JS event loop waiting for the JS debugger, I want to spin the JS event loop waiting for about:debugging or similar to connect.

[Possibly silly question] Can I double check that you don't want to channel ADB logcat messages towards the devtools console? You are still able to pull those messages from GeckoView using standard Android debugging tools, I hope.

Yep, I can. This is independent of ADB logcat.

Before we try to guess what would be an improvement for you or I keep having somewhat extravagant ideas, do you have any specific requests or thoughts about what would be an improvement for you compared to the current situation?

Sure! What I really want is to be able to invoke the GeckoView example App with ./mach run --jsdebugger --wait-for-jsdebugger, have the Android App start, show me native UI, start Gecko, and then spin waiting for my Desktop about:debugging session to connect. At that point I can view sources, set breakpoints, inspect state, etc, before saying "okay, go".

The issue that I was interested in debugging was system addon startup. I wanted to break somewhere in XPI provider and inspect the state of the disk and the state of the intermediate caches at that point. But I could only connect about:debugging at some indeterminate point much later.

Comment 5

[Soledad Penades [:sole] [:spenades]]

Thank you Nick, this helps a lot!

I will bring this up with them, and we'll get back to you as soon as we can (possibly with more questions O:-))

Comment 6

[Chris Peterson [:cpeterson]]

This sounds like a DevTools task. I'm tentatively moving this bug to the GeckoView Bugzilla component to DevTools.

Comment 8

[:Harald Kirschner :digitarald]

It came up before from the GeckoView team to debug JS executed during startup

Sole, did we figure out where this work has to happen? Is this mostly on DevTools or GeckoView?

Comment 9

[Soledad Penades [:sole] [:spenades]]

No, because people were on holidays. Julian or Alex might know this :-)

Comment 10

[Julian Descottes [:jdescottes]]

I don't have time to investigate this at the moment.

Comment 11

[Nick Alexander :nalexander [he/him]]

(In reply to Julian Descottes [:jdescottes] from comment #10)

I don't have time to investigate this at the moment.

I happen to be monkeying with DevTools startup for entirely different purposes, and I think I probably know how to do this now. I haven't time to investigate myself, but essentially the same logic implemented in DevToolsStartup.jsm for --wait-for-debugger needs to be done in the GeckoView DevTools startup path in GeckoViewRemoteDebugger.jsm. There may be additional monkeying with the GV startup path and Java, but fundamentally GV needs to spin the event loop when the appropriate flags are set.