Skip to content

Conversation

@christopherfujino
Copy link
Contributor

Fixes #111877

The issue was that the method declaration in the super class (Device.startApp) specifies covariant ApplicationPackage?, while the sub-class (ChromiumDevice.startApp) declares it covariant WebApplicationPackage, which is non-nullable. However, because of #55531, it is possible to run a Flutter app on a browser device even if the project does not specify a web target; thus, package could legitimately be null. However, ChromiumDevice.startApp specifies a non-nullable parameter, it is a runtime error. This was likely introduced during a null-safety migration, so this restores this functionality by making the parameter nullable (note that ChromiumDevice.startApp does not even reference the argument).

@flutter-dashboard flutter-dashboard bot added the tool Affects the "flutter" command-line tool. See also t: labels. label Sep 20, 2022
@override
Future<LaunchResult> startApp(
covariant WebApplicationPackage package, {
WebApplicationPackage? package, {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

not directly relevant to the fix, but this type doesn't need to be covariant, as sub-classes will use the exact same type

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is this true? Or is it because it has been labeled covariant in the base class definition here:

/// Start an app package on the current device.
///
/// [platformArgs] allows callers to pass platform-specific arguments to the
/// start call. The build mode is not used by all platforms.
Future<LaunchResult> startApp(
covariant ApplicationPackage? package, {
String? mainPath,
String? route,
required DebuggingOptions debuggingOptions,
Map<String, Object?> platformArgs,
bool prebuiltApplication = false,
bool ipv6 = false,
String? userIdentifier,
});

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is what true? That the type doesn't need to be covariant? Or that it's not relevant to the fix?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it true that a subtyped class can be passed as a valid parameter to a method.

Meaning I don't think because WebApplicationPackage is a subtype of ApplicationPackage that we can pass it as a valid type to the startApp method. But it works because we marked the type on super class a covariant

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We sync'd offline. To clarify my original statement, I can remove the covariant from the ChromiumDevice.startApp implementation because the super class has it marked covariant. TIL that covariant can be placed in either the superclass or subclass: https://dart.dev/guides/language/sound-problems#the-covariant-keyword

@eliasyishak
Copy link
Contributor

LGTM

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

autosubmit Merge PR when tree becomes green via auto submit App tool Affects the "flutter" command-line tool. See also t: labels.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

[tool_crash] _TypeError: (#0 ChromiumDevice.startApp (package:flutter_tools/src/web/web_device.dart))

2 participants