P0: Add a DevTools server that can launch the Chrome browser.

WebDev already has functionality to do this. We should move it into a simple package and support it in our server as well.

This is marked P1.5, but might be a blocker to launching DevTools correctly from VS Code on CrOS (VS Code may otherwise need to do its own browser location/launching - not a big deal, but can't reuse the existing code because the VS Code extension is TypeScript).

Thanks for escalating this! Raised to P0 as it is now on the critical path to fully support CrOS.
As some context, it is fine if FlutterWeb depends on installing linux chrome but regular Flutter on CrOS should not. Restricting to a single flutter app launching at a time in debug mode on CrOS is also fine.

but regular Flutter on CrOS should not.

Ah, ok - we'll definitely need to get to the bottom of exposing ports from the container then. I'll do some more testing and see what I can make work.

@devoncarew

it is fine if FlutterWeb depends on installing linux chrome but regular Flutter on CrOS should not

@devoncarew @jacob314 I've opened a PR to simplify port selection for DevTools at #535 however I've hit a problem... In order for a (non-Web) Dart/Flutter Mobile project to work outside of the container, we need both DevTools and the VM service exposed. As far as I can tell, the VM doesn't have an option to supply multiple ports, or control its behaviour if a port is taken. That failure if already bound a) is very slow (it retries internally) and b) leaves the app paused so the process doesn't even terminate:

dantup-macbookpro:Dart Mini Sample 1 dantup$ dart --pause-isolates-on-start --observe=8123 bin/main.dart
Observatory server failed to start after 1 tries
vm-service: isolate(935791540) 'main' has no debugger attached and is paused at start.  Connect to Observatory to debug.
Observatory server failed to start after 2 tries
Observatory server failed to start after 3 tries
Observatory server failed to start after 4 tries
Observatory server failed to start after 5 tries
Observatory server failed to start after 6 tries
Observatory server failed to start after 7 tries
Observatory server failed to start after 8 tries
Observatory server failed to start after 9 tries
Observatory server failed to start after 10 tries
Observatory server failed to start after 11 tries
Could not start Observatory HTTP server:
SocketException: Failed to create server socket (OS Error: Address already in use, errno = 48), address = localhost, port = 8123
#0      _NativeSocket.bind (dart:io-patch/socket_patch.dart:591:7)
<asynchronous suspension>
#1      _RawServerSocket.bind (dart:io-patch/socket_patch.dart:1206:26)
#2      _ServerSocket.bind (dart:io-patch/socket_patch.dart:1466:29)
#3      ServerSocket.bind (dart:io-patch/socket_patch.dart:1457:26)
#4      _HttpServer.bind (dart:_http/http_impl.dart:2520:25)
#5      HttpServer.bind (dart:_http:227:19)
#6      Server.startup.poll (dart:vmservice_io/server.dart:355:36)
<asynchronous suspension>
#7      Server.startup (dart:vmservice_io/server.dart:367:23)
<asynchronous suspension>
#8      main (dart:vmservice_io:253:12)

(hang)

Pretty much same thing for Flutter, but there's a slow build in front of it, then the app launches, then you see the above.

I can't come up with a good fix for this. We could hard-code a port, detect Observatory server failed to start after 1 tries in the output, terminate the process and apologise to the user (and offer to try with the next port), but that isn't a great experience. We could pick the port randomly from the known set to reduce the chance of overlaps if the user launches multiple sessions.

Ok, I got to the bottom of the container ports setup. You can access any port from the container by using the containers IP address. The reason it fails for things right now is that everything is binding to the loopback IP (the container of course has its own). The well-known ports we've seen are things that are tunnelled from ChromeOS to the container, so that localhost in ChromeOS reaches localhost in the container.

So, if we bind everything to the non-loopback local IP address (which is 100.115.92.something, the something maybe varying by device type), it could work...

This is assigned; is this in progress (or, is it expected to be complete within the next week or so)?

Yep, in progress. I have a PR open with some tweaks and then I think the only thing outstanding is passing some args through (for theme/hide) which I don't think is a lot of work, and I can take a look at tomorrow.

Server moved to its own package in Move server code to devtools_server package #539
launchDevTools service added in [DevTools Server] Listen for URIs and register launchDevTools service. #555

Navigation Menu

Repository navigation

P0: Add a DevTools server that can launch the Chrome browser. #463

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

P0: Add a DevTools server that can launch the Chrome browser. #463

Description

Activity

DanTup commented on Apr 13, 2019

jacob314 commented on Apr 13, 2019

DanTup commented on Apr 13, 2019

DanTup commented on Apr 15, 2019

DanTup commented on Apr 15, 2019

devoncarew commented on Apr 22, 2019

DanTup commented on Apr 22, 2019

kenzieschmoll commented on Apr 23, 2019

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions