[Bug] attachFile results in corrupted Microsoft Word file

[dotwork]

Current behavior:

I'm having a problem with attachFile. When uploading a valid docx file, it works on my test server if I do it manually, but when cypress does it, I get an error about it being corrupted from the server-side software that ingests it. I've tried various encodings, as well as no encoding.

Here is the file in question:
valid_minimal.docx

This is the code I am using:
cy.get('input#ebook-upload-content').attachFile(pathToFile, {mimeType: 'application/vnd.openxmlformats-officedocument.wordprocessingml.document', encoding: 'base64'});
`
However, the error is being sent back from server-side software, Aspose Words, so unless you have access to that software, you will not receive the error I did. There is no issue ingesting and processing this file in our many other unit and functional tests, so it appears that the file upload process via Cypress specifically is changing the file somehow, in a way that corrupts it so that it cannot be processed by Aspose.

Versions

Cypress 4.2.0
cypress-file-upload 4.0.3
Chrome Version 80.0.3987.149 (Official Build) (64-bit)
Firefox 72.0.1 (64-bit)
Linux Mint

[dotwork]

A bit more info...

When I read the file it is 18595 bytes, but when Cypress uploads, it has 31383 so for some reason it is almost doubling the length of the content. It has the same number of bytes for binary and base64 encodings, as well as with no provided encoding.

[dotwork]

And a bit more info...
My boss ran a small file through it and compared the bytes to the original. It seems the one that went through cypress is filled with EF BF BD which is the dreaded question mark symbol:
https://apps.timwhitlock.info/unicode/inspect?s=%EF%BF%BD

That explains why the uploaded version is almost twice the content length of the original.

[abramenal]

Hi, thanks for submitting the issue!

Right now I am not able to take a look into the issue properly.
In the meantime, I can suggest to check if the issue exist in v3 (previous major version):
https://github.com/abramenal/cypress-file-upload/tree/v3.5.3
Sorry about that. Not sure I can provide ETA on solving this issue in v4 since I am the only one contributor and maintainer. If you have ideas on fixing that, please feel free to open Pull Request and we can review it together.

Thanks for understanding.

[dotwork]

It does not exist in version 3 and that is what our company is using for now. We are hoping to move from Robot Framework to Cypress for all our functional testing, but we need to have firefox support before we can do that. We will consider looking into it and submitting a PR if we can resolve it, but I am not sure when (or if) that might be. Thank you!

…

On Thu, Apr 9, 2020 at 7:45 AM abramenal ***@***.***> wrote: Hi, thanks for submitting the issue! Right now I am not able to take a look into the issue properly. In the meantime, I can suggest to check if the issue exist in v3 (previous major version): https://github.com/abramenal/cypress-file-upload/tree/v3.5.3 Sorry about that. Not sure I can provide ETA on solving this issue in v4 since I am the only one contributor and maintainer. If you have ideas on fixing that, please feel free to open Pull Request and we can review it together. Thanks for understanding. — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#177 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACPHRS7VFYYIF2FVOYQ2MW3RLW7O3ANCNFSM4LSX2WVQ> .

[abramenal]

@dotwork did you use same encoding in v3? I think it should be binary for any version

[dotwork]

Yes, I have tried it with binary as well. I just happened to copy/paste the version where I was trying out base64 when I created the ticket. I have tried again with binary just now and confirmed again that this issue still exists and the new functionality is still corrupting files. Do you want to re-open this ticket? Should I submit a new one?

[abramenal]

Okay, let's keep this issue then.
For a bit of context, the plugin does not modify file contents in any way. I suppose the problem will be fixed with using proper file encoding. Let me get back to this by the end of the week, I'm just not sure how to test that properly.

So you're saying you used 'base64' encoding in v3 and it worked correctly, right?

[dotwork]

We are using v3.5.3 in our master branch, and yes we are using base64 encoding for these tests in Chrome and they all work great, testing .docx, .epub, .rft, .odt, .jpg, .zip. When I use binary in version 3 instead I get the error Failed to execute 'atob' on 'Window': The string to be decoded is not correctly encoded..

As far as testing, I should think that if you upload a docx file, and then download the file you uploaded, the download should have the same content length as the original version you uploaded. If the downloaded version is longer (different), then it's still modifying the file during upload somehow. I've attached the docx file we use in testing.

valid_minimal.docx

[tkardos-vintra]

I am also experiencing the same issue as documented, with a mp4. File size will have nearly doubled upon attachment and the file
data passed is corrupt. I've passed it with default parameters, also as binary, also as video/mp4.

Cypress 4.9.0
Cypress-file-upload: 4.0.7

Implementation looks like this:

fileToUpload = fileToUpload + ".mp4";
cy.fixture(fileToUpload).then((fileContent) => {
// cy.get('input[type="file"]').attachFile(fileToUpload);
cy.get('input[type="file"]').attachFile({
fileContent: fileContent,
fileName: fileToUpload,
mimeType: "binary",
});
});

Have tried calling attachFile directly without the fixture call as well.

[spragya]

I am seeing same issue with mp4 file upload. After upload file was corrupt . jpg and .pdf upload works fine.

[jerdaane]

After looking at #70 I could workaround this issue (where in my case a pdf file was corrupted) by using base64 encoding

	cy.fixture('/test-files/my-file.pdf', 'base64').then((data) => {
		cy.get('input[type="file"]').attachFile({
			filePath: '/test-files/my-file.pdf',
			fileContent: data,
			fileName: 'my-file.pdf',
			encoding: 'base64',
			mimeType: 'application/octet-stream',
		});
	});

[spragya]

I am seeing same issue with mp4 file upload. After upload file was corrupt . jpg and .pdf upload works fine.

cy.fixture('file_example.mp4', 'binary')
            .then(Cypress.Blob.binaryStringToBlob)
            .then(fileContent => {
                cy.get('[type="file"]').attachFile({
                    fileContent,
                    fileName: 'file_example.mp4',
                    mimeType: 'video/mp4',
                    encoding: 'utf8'
                })
            })

This worked for me. I am using Cypress : 6.0.0, cypress-file-upload: 4.1.1

[andrico1234]

This worked for me when trying to test uploading an encrypted file

thanks @jerdaane

After looking at #70 I could workaround this issue (where in my case a pdf file was corrupted) by using base64 encoding

	cy.fixture('/test-files/my-file.pdf', 'base64').then((data) => {
		cy.get('input[type="file"]').attachFile({
			filePath: '/test-files/my-file.pdf',
			fileContent: data,
			fileName: 'my-file.pdf',
			encoding: 'base64',
			mimeType: 'application/octet-stream',
		});
	});

[ibenjelloun]

Faced the issue while attaching a pptx file to input and adding the encoding fixed :

Failing code :

getInput().attachFile('file.pptx');

Working code :

getInput().attachFile({
          filePath: 'file.pptx',
          encoding: 'base64'
});

Edit sometime after :

After it worked for sometimes, its stopped working, can't make it work anymore.