-
Notifications
You must be signed in to change notification settings - Fork 75
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Help flutter register callbacks on chrome proxy service #1315
Comments
@sigmundch @grouma what do you think about the solution options above, or any alternative solutions? |
I'd admit I have little context here, so I don't have the full picture at the moment. Could you comment on what is the purpose behind the I can see from the Also, I noticed sprinkled through the flutter-tools code some if-then-elses to use a different protocol API for the web (example). That kind of code feels similar to your suggestion of having a between hook for registering extensions. Could it be that the problem here is that |
OK reading through flutter/flutter#81516 I see the reference to the same location I found: And I see that they can work around it using this indirection, but they'd like it to be abstracted away. A third idea would be to see if we can extend the service protocol to have a separate API like "getFlutterViewsIsolateIds" that bypasses the creation of the flutter views and directly returns the ids (since we see a lot of the sequence of getting views just to get the corresponding isolate ids as a next step). That would allow flutter_tools to use a single API that is consistent for both platforms /cc @jacob314 |
@sigmundch As far as I understand FlutterView is a ui isolate, so your third option could be just adding an VM Service API @sigmundch Clarification - by my first suggestion I meant calling some JS function (that would return runtime info about VM service, including the vm uri) from https://github.com/dart-lang/sdk/blob/82ea8416ed2a22e40c5c67252cb37bebec3a57e8/sdk/lib/_internal/js_runtime/lib/developer_patch.dart#L102 This way the engine could find the information it needs from the vm service using Service.getInfo() call to get the vm uri: https://github.com/dart-lang/sdk/blob/82ea8416ed2a22e40c5c67252cb37bebec3a57e8/sdk/lib/developer/service.dart#L62 This would be similar to what happens in the native VM - does it sound possible? Also, does it sound too complicated?:) |
The VM doesn't know anything about UI isolates as that's solely a Flutter construct (Dart programs don't have UI), so this wouldn't be something we'd want to add to the service protocol. However, isolates can be named AFAIK which should make it possible to pick a UI isolate out of a list, assuming the engine is naming its isolates. |
My preference would be to have a dart vm api the native flutter engine call to indicate than an isolate is a |
+1 on a more direct API, so that we are not "guessing" the data that the engine needs. @annagrin - on your suggestion, what would the runtime "VM" info look like for the web? |
@jacob314 Can this be done with isolate naming that @bkonyi suggested? Anyway, we would still need to solve the problem on the web where the engine cannot currently call the VM APIs but can register extensions. Hence my suggestion of implementing the VM info in https://github.com/dart-lang/sdk/blob/82ea8416ed2a22e40c5c67252cb37bebec3a57e8/sdk/lib/_internal/js_runtime/lib/developer_patch.dart#L102 so the web engine can get a VM uri and call VM api, including naming or getting the isolates. Alternatively, the web debugger will need to mark its only isolate as a ui/main/event loop isolate to match native flutter engine behavior - which seems too flutter-specific, for example, in case of a change of the marking. |
@sigmundch it seems to be already defined in we would only actually need the VM uri, which (I think) could be stored as some runtime data by the debugger. |
Flutter engine in native world registers
_flutter.listViews
extension on the VM. App registers extensions on the VM as well, and clients such as dart-code that are connected to flutter daemon call those extensions. Flutter daemon calls_flutter.listViews
before proceeding to call methods registered by the app.The web engine does not have information about the VM and its isolates so it cannot implement
_flutter.listViews
method that requires this information. For a short term solution, we are implementing_flutter.listViews
directly in dwds, but it would be cleaner and less bug prone to implement a solution somewhere in flutter (in case that API changes, for example).Possible solutions:
developer
library can provide information about VM uri so flutter web engine can connect to it andretrieve isolate information and implement
_flutter.listView
The text was updated successfully, but these errors were encountered: