search

flutter / devtools

Performance tools for Flutter
https://flutter.dev/docs/development/tools/devtools/
BSD 3-Clause "New" or "Revised" License
1.55k stars 319 forks source link

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

Closed jacob314 closed 5 years ago

jacob314 commented 5 years ago

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

DanTup commented 5 years ago

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

jacob314 commented 5 years ago

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.

DanTup commented 5 years ago

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.

DanTup commented 5 years ago

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 https://github.com/flutter/devtools/pull/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.

DanTup commented 5 years ago

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

devoncarew commented 5 years ago

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

DanTup commented 5 years ago

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.

kenzieschmoll commented 5 years ago