Skip to content

Conversation

@eliasyishak
Copy link
Contributor

@eliasyishak eliasyishak commented Aug 18, 2022

Fixes: #109450

  • I read the [Contributor Guide] and followed the process outlined there for submitting PRs.
  • I read the [Tree Hygiene] wiki page, which explains my responsibilities.
  • I read and followed the [Flutter Style Guide], including [Features we expect every widget to implement].
  • I signed the [CLA].
  • I listed at least one issue that this PR fixes in the description above.
  • I updated/added relevant documentation (doc comments with ///).
  • I added new tests to check the change I am making, or this PR is [test-exempt].
  • All existing and new tests are passing.

@flutter-dashboard flutter-dashboard bot added the tool Affects the "flutter" command-line tool. See also t: labels. label Aug 18, 2022
@eliasyishak
Copy link
Contributor Author

Need to create a test to be run in the device lab following instructions found here: https://github.com/flutter/flutter/blob/master/dev/devicelab/README.md

@eliasyishak eliasyishak marked this pull request as ready for review September 13, 2022 21:39
@jonahwilliams
Copy link
Contributor

I don't think this is the right approach: in general this feels far too restrictive, especially as it is perfectly reasonable for folks to give screenshots whatever extension they want or use non-ascii characters.

Is there an exception thrown if we create a file with an unsupported name, like "."? If so, we could catch that exception instead. But consider shifting from an allow based approach to a deny based approach

@eliasyishak
Copy link
Contributor Author

Yeah it definitely was a more restrictive approach, and that's understandable if we would like to make it less restrictive. We can remove any character restriction and file type restriction on the pattern and just make sure the directory is valid?

Because the tool does actually allow for files that don't even have any extensions, ie. -o image will produce a file for the user. Does that approach make sense?

@christopherfujino
Copy link
Contributor

Yeah it definitely was a more restrictive approach, and that's understandable if we would like to make it less restrictive. We can remove any character restriction and file type restriction on the pattern and just make sure the directory is valid?

Because the tool does actually allow for files that don't even have any extensions, ie. -o image will produce a file for the user. Does that approach make sense?

isn't it reading the extension and then determining what encoding to use based on that? so if you pass -o image, what kind of image is it creating? is there a default extension, or is it just not doing anything and exiting 0?

@jonahwilliams
Copy link
Contributor

As far as I can tell, the tool does not use the file extension to determine what kind of file output.

@christopherfujino
Copy link
Contributor

As far as I can tell, the tool does not use the file extension to determine what kind of file output.

this is simctl

@eliasyishak
Copy link
Contributor Author

I'm not sure how simctl handles it but I have seen that the file gets generated, although I wasn't able to open it on my mac. Which was why I initially thought to add the extension requirement and possibly expand to different file types as needed.

@jonahwilliams
Copy link
Contributor

but simctl isn't the only backend here, and based on the snapshot type argument we can also create a "skia" and "rasterizer" type

- added additional transformation for outputFile incase users pass a trailing directory delimiter (ie. '-o image.png/' will result in a file being output at $PWD/image.png
/// return a 0 exit code even if outputFile is not valid
static File validateOutputFile(File outputFile, FileSystem fs) {

// Will make sure that if the user passes '-o image.png/' the file
Copy link
Contributor Author

Choose a reason for hiding this comment

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

@jonahwilliams i added this additional functionality to catch any errors if the user provides a trailing delimiter. Do you think it's worth keeping this or should the tool throw an exception?

Copy link
Contributor

Choose a reason for hiding this comment

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

I would not modify the file the user provides to this script, either accept it if it is valid or deny if it isn't. Consider the case where someone uses this command in part of an automated test script, and said test script has a bug that gets an invalid path. You would want that to fail as soon as possible, instead of accidentally passing for some time, or failing because a different command that accepts a file didn't make the same change to the file name to make it valid

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Great point, I'll make the adjustments

const Platform platform = LocalPlatform();

// Conditional to check for trailing path separator
if (outputFile.path.endsWith(platform.pathSeparator)) {
Copy link
Contributor

Choose a reason for hiding this comment

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

This is available on path.

Comment on lines 204 to 205
'The provided path cannot end with a path separator\n'
'Path provided: "${outputFile.path}"'
Copy link
Contributor

Choose a reason for hiding this comment

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

I would rephrase this to indicate that we expect a file path but got a directory path.

Comment on lines 210 to 215
if (!fs.directory(outputFile.dirname).existsSync()) {
throwToolExit(
'The provided path to file needs to have a directory that exists\n'
'Directory: "${outputFile.dirname}" does not exist'
);
}
Copy link
Contributor

Choose a reason for hiding this comment

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

Use fs.file(outputFile).parent.existsSync() - I'm not sure if dirname includes the contents of absolute paths.

}

// Conditional for validating filename
if (outputFile.basename.isEmpty || outputFile.basename == '.') {
Copy link
Contributor

Choose a reason for hiding this comment

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

what about .. or ../?

});
});

group('Screenshot file validation', () {
Copy link
Contributor

Choose a reason for hiding this comment

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

Since all this command does now is check if the file exists, you only need a test case for 1) file exists and 2) file doesn't exist

Copy link
Contributor

@jonahwilliams jonahwilliams left a comment

Choose a reason for hiding this comment

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

LGTM

@eliasyishak eliasyishak added the autosubmit Merge PR when tree becomes green via auto submit App label Sep 14, 2022
@auto-submit auto-submit bot merged commit 0c829ca into flutter:master Sep 14, 2022
@eliasyishak eliasyishak deleted the flutter-screenshot-path-bug branch September 15, 2022 02:38
engine-flutter-autoroll added a commit to engine-flutter-autoroll/packages that referenced this pull request Sep 15, 2022
engine-flutter-autoroll added a commit to engine-flutter-autoroll/plugins that referenced this pull request Sep 15, 2022
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.

Flutter tools crashes when path for flutter screenshot is specified as .

3 participants