Dev tools remote debugging port on ChromeOS

[Robert Flack]

Hi all,

I've run into many situations where it would be useful to be able to connect to the remote debugging dev tools on my ChromeOS device. I have changed /sbin/session_manager_setup.sh, adding --remote-debugging-port=1337 to the list of chrome flags. Since it seems the remote debugger only listens for local connections I then forwarded the port using ssh device-ip -L 1337:localhost:1337. When I connect (to http://localhost:1337) from my desktop I gets the list of web contents which can be debugged, but clicking on any of them I get a 404 error, and the "Oops! This link appears to be broken." page, the URL for which is http://localhost:1337/devtools/devtools.html?host=localhost:1337&page=8 in case anyone can spot any obvious problems. As would be expected, I get the same 404 error when attempting to observe a particular page from the ChromeOS device.

Does/has anyone used --remote-debugging-port on ChromeOS and had any success with it? Does anyone have any suggestions?

Thanks,

Rob

[Mikhail Naganov]

[+chrome-devtools-team]

I'm not sure that DevTools frontend is deployed with ChromeOS.

You can try using the externally hosted frontend. Change the
"http://localhost:1337/devtools/" prefix in your second URL to
"http://chrome-devtools-frontend.appspot.com/static/19.0.1071.0/"

> --
> Chromium Developers mailing list: chromi...@chromium.org
> View archives, change email options, or unsubscribe:
> http://groups.google.com/a/chromium.org/group/chromium-dev

[Robert Flack]

This works, thanks!!  But why don't we ship the frontend with ChromeOS?

[Pavel Feldman]

We surely do. However, code paths for serving devtools front-end
internally and via remote debugging are different. Could you please
file a bug on the matter and CC it to me? I'll then check why front-
end files are not making their way to the client.

Using external front-end as Mikhail suggested would work, but since
different versions of front-end could contain subtle differences, it
may result in unexpected behavior. So we don't recommend it to our
clients.

Thanks
Pavel

[Pavel Feldman]

Fix for remote debugging of ChromeOS landed as
http://src.chromium.org/viewvc/chrome?view=rev&revision=129648. Thanks
for the heads up.

Regards
Pavel

[Robert Flack]

Thanks I was actually in the process of filing a bug for it.

[Rick Byers]

Thanks Pavel, glad this is fixed!

Rob, it's probably still worth filing a bug so people can see this is a known issue with a fix in M20.  Presumably this fix won't get back-ported to M19, right?  I'm pretty sure I've seen this work in previous ChromeOS releases.

Rick

[Pavel Feldman]

On Mar 29, 11:22 pm, Rick Byers <rby...@chromium.org> wrote:
> Thanks Pavel, glad this is fixed!
>
> Rob, it's probably still worth filing a bug so people can see this is a
> known issue with a fix in M20.  Presumably this fix won't get back-ported
> to M19, right?  I'm pretty sure I've seen this work in previous ChromeOS
> releases.

I am not sure it is even necessary to file it: remote debugging has
never been enabled for ChromeOS builds, we've never advertised it as
an end-user feature. I think you need a rooted device for that. I
guess you are talking about the DevTools themselves that used (and
still do) work on the ChromeOS!

Pavel

[Rick Byers]

On Thu, Mar 29, 2012 at 3:51 PM, Pavel Feldman <pfel...@chromium.org> wrote:

On Mar 29, 11:22 pm, Rick Byers <rby...@chromium.org> wrote:
> Thanks Pavel, glad this is fixed!
>
> Rob, it's probably still worth filing a bug so people can see this is a
> known issue with a fix in M20.  Presumably this fix won't get back-ported
> to M19, right?  I'm pretty sure I've seen this work in previous ChromeOS
> releases.

I am not sure it is even necessary to file it: remote debugging has
never been enabled for ChromeOS builds, we've never advertised it as
an end-user feature. I think you need a rooted device for that. I
guess you are talking about the DevTools themselves that used (and
still do) work on the ChromeOS!

Really?  I thought that shortly after remote debugging was announced I had used it with ChromeOS (yes - a 'rooted' developer image, modifying session_manager_setup), but maybe I'm mistaken (I may be getting confused with a hack we did to allow remote debugging of content-shell when running on a CrOS device).  Anyway certainly not an end-user feature - just a really handy chrome developer feature.

Anyway, thanks for getting it working!

[Brenton Simpson]

There's a whole series of tools emerging that use the remote-debugging API to improve the web development workflow (including SublimeWebInspector and Brackets).  Unfortunately, there doesn't appear to be an easy way to enable it on a Chromebook.  (So far as I can tell, you'd have to edit a read-only partition, which would break auto-updating.)

I realize that dev_mode isn't a supported end user feature, but a rooted Chromebook has the potential to be an amazing development platform.  (It's already become my primary machine.)

What would it take to allow the remote-debugging-port flag to be set without modifying the ChromeOS partition?  Perhaps session_manager_setup could check for flags in ~/.extra_chrome_flags and include them (shouldn't be a security concern as long as the file is in a place you need to be in dev_mode to write to).

I know Pavel is hard at work making the Dev Tools capable of replacing a code editor, but in the mean time, it'd be great to enable remote debugging on my Chromebook.  =)  What do you think?

Thanks guys!  Keep up the great work!

[Vladislav Kaznacheev]

Hi Brenton,

I can think of a simple way enable HTTP debugging: instead of passing a command line flag we could theoretically surface this option in chrome://flags page which is editable by the device owner. However before we talk about doing that I would really like to know more about your usage scenarios. What tools you are using to connect to DevTools? 

I am asking because as a matter of fact HTTP is not the preferred way for an external tool to interact with Chrome DevTools. A much better and more secure way is "chrome.debugger" extension API. An external IDE would need a companion extension installed on the target Chrome, and then talk to it over a TCP connection or something like that. This is what WebStorm IDE does. You can install such an extension on Chromebook, so the only remaining problem is connecting this extension with your host machine which I guess not a big problem on a rooted device.

Best regards,

  Vlad

--

--
Chromium Developers mailing list: chromi...@chromium.org
View archives, change email options, or unsubscribe:
http://groups.google.com/a/chromium.org/group/chromium-dev

To unsubscribe from this group and stop receiving emails from it, send an email to chromium-dev...@chromium.org.

[Brenton Simpson]

Thanks Vlad.  I was hoping there'd be an option like that, but didn't want to be too presumptuous.  =)

I'm the maintainer of https://github.com/appsforartists/pixel_webdev which helps web developers with limited Linux experience install all their typical tools on a Chromebook.  It's uses crouton to install these native apps in a sandboxed chroot.  The code editor I'm including is Sublime, which has a plugin that integrates really closely with Chrome on other platforms, but it's built around the HTTP API so I can't test it on my Chromebook.  The plug-in is called SubIimeWebInspector, and it's on GitHub here: https://github.com/sokolovstas/SublimeWebInspector  

I know Brackets also makes heavy use of the HTTP API.

For these external tools that utilize the HTTP API, how would they move to an extension?  It seems to me that they'd end up implementing their own ad hoc HTTP API (or more likely, trying to re-implement the present HTTP API, but from an extension).  That would be more error-prone, less robust, and presumably less secure than utilizing Chrome's own implementation.

Do you know of a better solution?  Making remote-debugging-port settable from a Chromebook certainly has the most bang-for-the-buck, but if there's a better way, I'll certainly open to it.

Thanks!

Brenton

[Pavel Feldman]

On Fri, Aug 16, 2013 at 9:07 PM, Brenton Simpson <bre...@theillustratedlife.com> wrote:

Thanks Vlad.  I was hoping there'd be an option like that, but didn't want to be too presumptuous.  =)

I'm the maintainer of https://github.com/appsforartists/pixel_webdev which helps web developers with limited Linux experience install all their typical tools on a Chromebook.  It's uses crouton to install these native apps in a sandboxed chroot.  The code editor I'm including is Sublime, which has a plugin that integrates really closely with Chrome on other platforms, but it's built around the HTTP API so I can't test it on my Chromebook.  The plug-in is called SubIimeWebInspector, and it's on GitHub here: https://github.com/sokolovstas/SublimeWebInspector  

I know Brackets also makes heavy use of the HTTP API.

For these external tools that utilize the HTTP API, how would they move to an extension?  It seems to me that they'd end up implementing their own ad hoc HTTP API (or more likely, trying to re-implement the present HTTP API, but from an extension).  That would be more error-prone, less robust, and presumably less secure than utilizing Chrome's own implementation.

The main reason remote debugging is behind a command line flag in Chrome is security. Otherwise, apps running on local host would be able to attach to the running Chrome instance for inspection. So running with that command line flag is a very sensitive step security-wise. That's why the official (recommended) model involves implementing an extension with corresponding permissions + shows an infobar whenever there is a connection to warn user. WebStorm does it this way. I am surprised Brackets does not - they are a web app, they should be able to do it with no problem.

 

Do you know of a better solution?  Making remote-debugging-port settable from a Chromebook certainly has the most bang-for-the-buck, but if there's a better way, I'll certainly open to it.

Have you tried using workspaces? That's when you use Chrome DevTools itself as an editor. (http://www.html5rocks.com/en/tutorials/developertools/revolutions2013/#toc-workspaces)

Regards

Pavel

[Brenton Simpson]

Developers should be able to test their work across platforms without having to learn a new set of tools for each one.  Since you guys published the Remote Debugging Protocol and bundled it into WebKit, I'm sure you understand the utility of this.  Testing an app in Firefox for Android should be as easy as testing it in Chrome on my laptop (and vice versa).  The tooling doesn't need to be coupled to a particular browser vendor or engine.  An ecosystem of rich tools supporting RDP incentivizes other vendors to build compatible implementations into their browsers too, making it easier for web developers to focus on building quality experiences without wasting time learning how browser X reinvented the debugger. 

I certainly understand why you prefer the extension security model versus the HTTP API, and why this has led to the HTTP API being an opt-in experience on most platforms.  Unfortunately, there's no way to opt-in on ChromeOS.  Is there any reason we shouldn't move the remote-debugging-port switch into chrome:flags (as Vlad suggested)? 

Thanks again guys for the awesome work!

Brenton

PS: I haven't played with Workspaces lately.  The last time I tried most of the useful features hadn't landed in stable yet.  I'll have to take another look.  (I did see you guys at Google I/O though, and the work you're doing on Workspaces is impressive!)

PPS: Exposing the internals of the engine will always cause security concerns, but it seems like there are some simple things we can do to mitigate those risks.  The most obvious option is to display a dialog when a client tries to connect asking the user to confirm that they're expecting a connection.  (Firefox for Android does it this way.)  Over time, the API can also be evolved to provide clients with a method of authenticating themselves and requesting a limited set of permissions to do what they need to do.  (You currently get this for free in the extension model, albeit by giving up the promise of interoperability.)

Security is always a hard problem that most developers aren't great at solving.  If developers are encouraged to use the extensions API to talk to their external apps, inevitably they're going to end up reimplementing something like the HTTP API so they can talk to their non-browser-based apps.  In doing so, they're going to accidentally expose many of the same security holes that you're trying to solve by discouraging HTTP in the first place.  Any effort you guys can make to build secure infrastructure that everyone can share into the HTTP API, the better off we'll all be.

On Monday, August 19, 2013 3:15:49 AM UTC-7, Pavel Feldman wrote:

The main reason remote debugging is behind a command line flag in Chrome is security. Otherwise, apps running on local host would be able to attach to the running Chrome instance for inspection. So running with that command line flag is a very sensitive step security-wise. That's why the official (recommended) model involves implementing an extension with corresponding permissions + shows an infobar whenever there is a connection to warn user. WebStorm does it this way. I am surprised Brackets does not - they are a web app, they should be able to do it with no problem.

[Brenton Simpson]

Weird, cause I sent it from the online thread.  (Now, there's a message where it used to be that says "This message has been deleted.")

My concern is that you can't add a command line flag to ChromeOS without modifying the read-only partition (which would evict you from the auto-update program).  Am I mistaken about that?  Is there a way to set remote-debugging-port without breaking auto-update?

Thanks!

Brenton

On Mon, Sep 2, 2013 at 6:22 AM, Pavel Feldman <pfel...@google.com> wrote:

Somehow this email did not reach me (nor it is in the thread online).

I don't think we should add an about:flag for this use case. Entering such mode on ChromeOS and toggling between screens with Chrome and IDE is not the experience we'd like to grant our users with. If one still wants it, adjusting the startup parameters for Chrome does not sound like a great effort (comparing to running Sublime under ChromeOS).

Regards

Pavel

On Thu, Aug 29, 2013 at 5:54 PM, Vladislav Kaznacheev <kazna...@google.com> wrote:

---------- Forwarded message ----------
From: Brenton Simpson <bre...@theillustratedlife.com>
Date: Thu, Aug 29, 2013 at 3:16 AM
Subject: Re: [chromium-dev] Re: Dev tools remote debugging port on ChromeOS
To: chromi...@chromium.org
Cc: Brenton Simpson <bre...@theillustratedlife.com>, Vladislav Kaznacheev <kazna...@google.com>, Robert Flack <fla...@chromium.org>, Mikhail Naganov <mnag...@chromium.org>, Matthew Bolohan <mbol...@chromium.org>

Pavel,

Any objection to Vlad's proposal to expose remote-debugging-port in about:flags on ChromeOS?  Between the ChromeOS firewall and the obscurity of about:flags, the surface area for accidental security boo-boos seems fairly small.

Cheers,

Brenton

On Monday, August 19, 2013 3:15:49 AM UTC-7, Pavel Feldman wrote:

[Rick Byers]

On Mon, Sep 2, 2013 at 12:26 PM, Brenton Simpson <bre...@theillustratedlife.com> wrote:

Weird, cause I sent it from the online thread.  (Now, there's a message where it used to be that says "This message has been deleted.")

My concern is that you can't add a command line flag to ChromeOS without modifying the read-only partition (which would evict you from the auto-update program).  Am I mistaken about that?  Is there a way to set remote-debugging-port without breaking auto-update?

Putting your device in dev mode doesn't disable auto-update.  So you can add this flag without breaking auto-update.  But the next update will clobber any rootfs modifications you've made, so it's still a pain.  

I agree that there should be some way to enable remote debugging of chromeOS without relying on auto-update.  I don't know what the right path forward is though - I guess it's largely a security policy question.

[Brenton Simpson]

Crap!

I just tried mounting rootfs as read/writable using:

> sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partition 2
> sudo /usr/share/vboot/bin/make_dev_ssd.sh --remove_rootfs_verification --partition 4

and now ChromeOS won't start!  It says "ChromeOS is missing or damaged.  Please insert a recovery USB stick or SD card."

I tried following the official instructions on this page, but was receiving an error about choosing a partition.  So, I followed these instructions, and now I can't get passed the BIOS.  First, I get the dev mode warning.  After Ctrl-D'ing passed that, I get stuck on the ChromeOS missing page.

Is there an easy way to recover from this without having to erase the SSD?  When make_dev_ssd was running, it looked like it made a backup of kernel A and put it somewhere. 

[Rick Byers]

Yikes, I don't know why that would happen (but I'm not an expert on the CrOS boot/verification process).  Did you install the dev mode firmware (chromeos-firmwareupdate --mode=todev) as listed by the instructions here: http://www.chromium.org/chromium-os/developer-information-for-chrome-os-devices/chromebook-pixel? I've done that and used make_dev_ssd (well ateast run it on the one --partition the error message suggests) many times without issue.

I'm not aware of any way to recover that doesn't wipe the SSD.  Presumably you could take the drive out to get any non-encrypted data off, and there may be some way to fix things up with a servo board but I've never done that myself (and it requires special hardware).

Sorry for the trouble!

  Rick

[Brenton Simpson]

Honestly, I'm not sure.  Some helpful stranger put it in dev mode for me while I was waxing philosophical with Pavel at the Chrome booth at I/O.

I *think* everything important is backed up on Github and/or Dropbox, so I suppose I can just wipe it again.  I was just hoping I wouldn't have to, just in case there's something important that I forgot (and because Crouton takes too long to download).

So, just to be sure, I can use make_dev_ssd to make my rootfs r/wable, and it will just be kicked back to its original state on auto-update?  I thought I'd read that r/w mode disables auto-update.

Thanks Rick.

Brenton

[Rick Byers]

On Wed, Sep 4, 2013 at 12:22 PM, Brenton Simpson <bre...@theillustratedlife.com> wrote:

Honestly, I'm not sure.  Some helpful stranger put it in dev mode for me while I was waxing philosophical with Pavel at the Chrome booth at I/O.

I *think* everything important is backed up on Github and/or Dropbox, so I suppose I can just wipe it again.  I was just hoping I wouldn't have to, just in case there's something important that I forgot (and because Crouton takes too long to download).

So, just to be sure, I can use make_dev_ssd to make my rootfs r/wable, and it will just be kicked back to its original state on auto-update?  I thought I'd read that r/w mode disables auto-update.

It's been awhile since I've done it so it's possible something has changed.  But I've done this several times in the past and still gotten updates (the updates just clobber my modifications).

[Adenilson]

Dear friends

I have researched about the subject and this post seemed the closest I could find related to the use case I'm trying to address.

I got the following scenario: running profiling in web content in 2 different chrome books, while using my workstation. What works today is to open the content on each chrome book and look at the profiling data/timeline using inspector, in the chromebook itself.

What I wanted to do: use my workstation to easily compare, side by side, the profiling data (more specifically the Timeline) collected in each chrome book (i.e. have two windows, each one attached to the remote browser instance of each chrome book).

So here comes the question: is there a way to enable remote debugging in chromeos? I'm totally ok using 'developer mode' or ssh to maybe tunnel the connection. I'm just wondering if anyone has done this recently (like past chrome M50-M52)?

In worst case, could I just dump the data in each chromebook and next visualize it in my computer?

Best regards


Adenilson Cavalcanti
ps: it would be really nice if remote debugging in chromeos was as easy to use as it is in Android.

[Robert Flack]

(Replying from my chromium account)

If you're okay using dev mode you can do this by adding the flag to /etc/chrome_dev.conf. Assuming you want to use port 1337 (note: these instructions all require being run as root):

1. First you'll need to be able to write to /etc/chrome_dev, you can do this by removing rootfs verification and remounting your filesystem to be writeable (will persist with reboots):

mount -o rw,remount /

Or bind mounting /etc/chrome_dev.conf in /tmp (this will be lost when you reboot but doesn't require disabling rootfs verification):

cp /etc/chrome_dev.conf /tmp/chrome_dev.conf

mount -o bind /tmp/chrome_dev.conf /etc/chrome_dev.conf

2. Then, add the remote-debugging-port flag to chrome_dev.conf:

cat >> /etc/chrome_dev.conf <<EOF

--remote-debugging-port=1337

EOF

3. Lastly, you'll also have to open up the port since chromeos by default blocks incoming connections:

iptables -A INPUT -p tcp --dport 1337 -j ACCEPT

4. Restart chrome and connect to dev tools remotely.

service ui restart

--

[Adenilson]

Robert

Thanks a lot for the detailed instructions, it worked perfectly!

Cheers

Adenilson