(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.