react: Allow attachments with unsupported file types to be downloaded

[mpkorstanje]

When I attach an application/octet-stream I want to be able to download the attachment and open it using a dedicated application. This also applies to all other supported and unsupported types.

Additionally when I attach a file with a file name, I this file name should be reflected in the download. So for example when I download the file attached with the code below then the file dialog should suggest cucumber-growing-on-vine.jpg as the file name.

        Path path = Paths.get("src/test/resources/features/attachments/cucumber-growing-on-vine.jpg");
        byte[] bytes = Files.readAllBytes(path);
        String fileName = path.getFileName().toString();
        scenario.attach(bytes, "image/jpg", fileName);

Also, nothing can plausible render an application/octet-stream so the request for a PR isn't necessary here.

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed in a week if no further activity occurs.

[zulfikarayub]

i am also facing the same issue ,can you help on this b and found a work around to it please see this code can help you

final byte[] screenshot = ((TakesScreenshot) driver).getScreenshotAs(OutputType.BYTES);
// embed it in the report.
scenario.attach(screenshot, "image/jpg", "jpg");

in your code there no need of changing it to string i think you can directly write your code like this

Path path = Paths.get("src/test/resources/features/attachments/cucumber-growing-on-vine.jpg");
byte[] bytes = Files.readAllBytes(path);

    scenario.attach(bytes, "image/jpg", "jpg");

[aslakhellesoy]

@mpkorstanje When you say download - I assume you mean "move it from my browser's memory to a file on my file system".

There File API has been discontinued, but there is a workaround called FileSaver.

I'd rather not rely on something like this as it seems fragile. I'd rather implement the download functionality properly, i.e. expose an URL the attachment can be downloaded from.

This means we need to split attachments out from the message stream. This would also improve performance as discussed here.

I propose we add an extra url property to Attachment. This will not be set by Cucumber, but it can be set by a post-processor of the messages. For example:

When an Attachment message is processed, write the contents of data to a file. Set the contents of data and content_encoding to null, and set url to the URL of the file.

For the standalone HTML formatter, the URL could be relative to the HTML file. For a system like Cucumber Reports it would be relative to the report URL (or it could be an absolute URL pointing elsewhere).

If we implement this for the HTML formatter, it means it will no longer produce a single file. The CLI interface of the HTML formatter could no longer write the HTML to stdout, but would instead have to take a filename as an argument (so we know where to write attachments).

Splitting attachments out like this would also address some performance/size issues we have with the current design. Message streams can be dozens of megabytes, and can take dozens of seconds to download/render. By splitting attachments out, pages would load much faster, and we get the download links for free.

[aslakhellesoy]

A partial fix for this is cucumber/common#1183. We also need to update @cucumber/react:

• Display "visual" attachments when they have a url but no body
• Display a "download" link for attachments that cannot be displayed.

[mpkorstanje]

@mpkorstanje When you say download - I assume you mean "move it from my browser's memory to a file on my file system".

I'd consider the exact way a file gets to ~/Downloads to be an implementation detail.

I'd rather not rely on something like this as it seems fragile.

I know. 😆

eligrey/FileSaver.js#330 (comment)

If we implement this for the HTML formatter, it means it will no longer produce a single file.

Ouch. That's a breaking change. I wasn't planning on a breaking change in Cucumber JVM until the Cucumber expressions parser and before/after all hooks were done which are both still miles away and I'd like to group them all together. Can we come up with a way to make this a non-breaking change?

[aslakhellesoy]

Ouch. That's a breaking change.

The API is the same, the only difference is that there would be an attachments directory next to the generated html file. Would you consider that to be a breaking change? It's only really a change to what files are generated.

Perhaps we could hide it behind a feature toggle until we bump the major version again? Unless you specify CUCUMBER_HTML_DETACH_ATTACHMENTS, everything will still be in a single HTML file?

[mpkorstanje]

The API is the same, the only difference is that there would be an attachments directory next to the generated html file. Would you consider that to be a breaking change? It's only really a change to what files are generated.

That could be reasonable. But I'm not sure I can estimate the impact.

Perhaps we could hide it behind a feature toggle until we bump the major version again?

That would definitely work.

[maresja1]

Is there any progress on this one? The attachments can be stored in the HTML file as inlined base64. We would really like this feature. I am willing to look at making a PR, if someone gives me some basic pointers. Thx