Dropping file crashes browser tab with RESULT_CODE_KILLED_BAD_MESSAGE message

[MichalKrakow]

Initial checklist

• I understand this is a bug report and questions should be posted in the Community Forum
• I searched issues and couldn’t find anything (or linked relevant results below)

Link to runnable example

No response

Steps to reproduce

So i assume this is rather specific error on my configuration part, but also that's something i couldnt solve by searching documentation or other issues on this gh page.

Uppy works as expected on localhost, or inside container. After publishing to AWS it just started crashing. Server side dont return eny errors and dropping event immediatly crashes Chrome and Edge with message "RESULT_CODE_KILLED_BAD_MESSAGE". Brave for some reason still works.

Have tried to hook into 'onDrop' or 'onBeforeFileAdded' with debugger but it crashes sooner, so cant really pinpoint the issue.

Expected behavior

Dropping files on AWS hosted instance should not crash browser.

Actual behavior

As described above, browser crashes on drop event. Any help regarding this would be greatly appreciated.

[MichalKrakow]

Little update,
So i've updated all uppy related imports, i've stripped it down to bare instatiated 'drag-drop' component with:

new Uppy({
debug: true,
autoProceed: true,
meta: { context_id, context_type }, 
})

context_id and type are provided,
so on localhost i get: "No uploader type plugins are used"
on production when selecting by system filepicker (clicking on drag-drop component) also i get "No uploader type plugins are used" message,
BUT
dropping enything to the component on production server causes it to crash browser tab.
So i'm absolutly destroyed by this.

Dropping on regular file input allows for uploads no problem. Its has something to do with uppy configuration that's related to base url or something - really im in the dark here.

[Murderlon]

Hi, this seems to be related to #976. I'll take a look when I have some time.

[Murderlon]

Can you confirm your site crashes because production is not on HTTPS as mentioned (#976)?

[MichalKrakow]

Yes, migrating to https fixed ts. Tab is not crashing. Side question dough, why the hell it works fine on Brave browser?

[Murderlon]

A browser tab should never crash so it's a bug in the version of Chromium which Chrome and Edge use. Brave either uses a different version, or has altercations which prevent this from happening.

[chiqui3d]

Same problem, after some time without using the project locally with Uppy, and now when I come back I find that error, I'm in local without HTTPS and with debug active, it should work, right? Or it doesn't matter if I have debug active, it has to be with HTTPS by force?

[chiqui3d]

I have to say that I am not under the url http://localhost, I am under http://mytestdomain.test

[chiqui3d]

Now accessing through https to my local domain, but without a valid certificate, it works. I don't understand anything.

[Murderlon]

Only localhost is an exception, if you use another HTTP domain things will fail. This is not Uppy specific, it would happen to any project that leverages certain browser APIs.

[long76]

https://stackoverflow.com/questions/66664179/constructing-large-js-blob-crashes-tab-with-result-code-killed-bad-message-on-ch

it's can fix error on non https servers?

[kylerobinson-finocomp]

Has there been any update on this issue and if there is a way to resolve it?

Only noticed it today in our test environment (non-HTTPs), works fine on localhost and I assume will work fine on a secured environment. Can't seem to find much else around making it work on non-HTTPs environments.

Uploading a file normally works fine, as does drag/drop in another browser (I tested on Safari).

[Murderlon]

The way to resolve it is by using HTTPS for live environments, it is required.

[mjau-mjau]

I'm also curious if there has been any progress on this. There seem to be some conflicting explanations in this post, but the fact is that CHROME browser crashes on drag-and-drop into Uppy on non-SSL (non-https) hosts. Test here:
http://nossl.files.gallery/

I read that this is caused by "any project that leverages certain browser APIs", but this statement does not seem like a proper explanation. Other javascript batch file uploaders work fine in non-SSL mode.

I'm of course of the opinion that every website should use SSL, but I have an app https://www.files.gallery which many users publish on non-SSL hosts. It can be quite annoying when it says "Drop files here ..." and the browser crashes.

Couldn't there at least be an option to disable "drop files" so it could be disabled on non-SSL?

[mifi]

I think we're not going to spend any time researching an obscure chrome bug that only happens for non-https. But if you want to try to find the cause and a workaround that is not too complex, I'm sure we could accept a PR for that.

Couldn't there at least be an option to disable "drop files" so it could be disabled on non-SSL?

I think an option for disabling the drag-drop code could make sense. However if that option also has to change the dashboard text from Drop files here or browse files to something else (and possibly other texts), then I'm not sure if it's worth it, as it will complicate UI design and testing.

[mjau-mjau]

I agree it's clumsy to resolve an issue in dashboard that only applies for non-SSL Chrome, especially in regards to texts. In my case (and possibly others), the major concern is the text "Drop files here ...", which invites to dropping files yet crashes the browser window. Here is my nasty fix:

// if !https && !localhost && Chrome browser, add class `uppy-chrome-non-ssl`
if(location.protocol !== 'https:' && location.hostname !== 'localhost' && /Chrome/i.test(navigator.userAgent)) document.querySelector('.uppy-Root').classList.add('uppy-chrome-non-ssl');

/* make text invisible */
.uppy-chrome-non-ssl .uppy-Dashboard-AddFiles-title {
  font-size: 0;
}
/* resize text in button */
.uppy-chrome-non-ssl .uppy-Dashboard-browse {
  font-size: 2rem;
}

[mifi]

the workaround is quite simple, just check for window.isSecureContext before calling item.getAsFileSystemHandle. created a PR: #4310

[long76]

please reopen it's broken in last releases

[long76]

https://github.com/transloadit/uppy/blob/main/packages/%40uppy/utils/src/getDroppedFiles/utils/webkitGetAsEntryApi/index.js
why fix was commented????

[mifi]

Which error are you getting now? getAsFileSystemHandle is now commented out so i dont see how you can get the same error. Reason (from commit):

disable experimental getAsFileSystemHandle
it seems to be causing problems when dropping folders with subfolders in newest chrome
e.g a folder with 50 files and a subfolder which in turn has another 50 files

[long76]

i got the same error, chrome crash, set version to 3.6.1 and all works great

[long76]

Reason (from commit):

disable experimental getAsFileSystemHandle
it seems to be causing problems when dropping folders with subfolders in newest chrome
e.g a folder with 50 files and a subfolder which in turn has another 50 files

i see. thanks. skip this message but now chrome crash again

[mifi]

I tried to reproduce it now locally by running a dev server npm run dev:with-companion and with host http://192.168.10.120:5173/, I also tried to update my /etc/hosts file and use http://mifitest:5173/, however I cannot reproduce it in latest chrome. maybe google has fixed the issue.
What was the steps to reproduce again? Just drag-drop a file into uppy in chrome?

[long76]

Just drag-drop a file into uppy in chrome?

Yes. I can't try in new chrome now i can do it after few weeks. I'll keep you informed.

[mjau-mjau]

Not sure exactly what has been fixed and/or if Chrome has evolved, but drag-and-drop now definitely works in non-SSL mode with Uppy 3.9.0 and Chrome 112. Thanks!

[mifi]

closing for now then!

[long76]

confirm it. Test pass on Chrome 110.
package.json

{
  "dependencies": {
    "@uppy/core": "^3.2.0",
    "@uppy/dashboard": "^3.4.0",
    "@uppy/drag-drop": "^3.0.2",
    "@uppy/drop-target": "^2.0.1",
    "@uppy/file-input": "^3.0.2",
    "@uppy/locales": "^3.2.1",
    "@uppy/progress-bar": "^3.0.2",
    "@uppy/react": "^3.1.2",
    "@uppy/status-bar": "^3.1.2",
    "@uppy/xhr-upload": "^3.2.0",
  }
}