Chrome aw-snap [works on version 4.3.7]

[marky291]

I am building a web service where a user can upload and configure a 'card' which inherits a live preview of the vue instance as you modify the configurator component, the uploading works great throughout however I have narrowed it down to a total of 5 images allowed, where anything more will crash chrome on accordian tab change, here is a preview of the tab.

A preview of the uploading

Once complete we can swap tabs

Swapping tab back to the upload images accordian tab, crashes after**** showing the content!

If the max-files setting is set to 5, it works fine with no crashing, it only happens when 5+ images are used, which leads me to believe it could be a resulting issue with filepond

Safari does not produce a crash.

Environment	Version
OS	MacOS
Device	Macbook Pro
Browser	Chrome Version 76.0.3809.87 (Official Build) (64-bit)

[marky291]

I have tried every version all the way down to 4.3.7 and is the last release where it works without this crash. originally believed it was the vue-filepond #101

[rikschennink]

Does this happen with the plain JavaScript FilePond version (not running in Vue)? This could have to do with the MutationObserver added to the Vue wrapper (but that would not explain why it doesn't occur with max files of 5).

[marky291]

Im using latest vue-filepond, with version 4.3.7 of this repo, its working good. The accordian is a vue component too, if thats a case of memory usage or leaking idk, never tried the non-vue version. Working with any amount of files again :)

[rikschennink]

Can you try with latest vue-filepond version? https://github.com/pqina/vue-filepond/releases/tag/5.1.3

[marky291]

"filepond": "4.4.12", "vue-filepond": "^5.1.3", Crashes.

"filepond": "4.3.7", "vue-filepond": "^5.1.3", Works

[rikschennink]

So 4.3.8 causes the issue? Or one of the versions in between?

[marky291]

4.3.8 has the crash and everything above :O, thanks for the response.

[marky291]

Might have something to do with ? Vue Documentation

I have tested it with this, maybe I used it wrong, still dosn't explain why only crashes later then then version 4.3.7

[rikschennink]

@marky291 I'm not sure, if you know the amount of instances you're creating then this sounds like a good idea instead of constantly destroying and creating new ones.

[rikschennink]

@marky291 Is this still an issue?

[marky291]

Will update to latest shortly and test

[marky291]

Works on latest version "filepond": "^4.6.1", "vue-filepond": "^5.1.3",

Much appreciated support :)

[rikschennink]

Fantastic, glad to hear that!

I'll close the issue then.

[mverstegen]

Sorry, but i still got this error with all versions in plain javascript when opening modal or using bootstrap collapse. Even when i open the element inspector in chrome and hover over the html it crashes. when removing filpond application works normally and never crashes. Who can help me?

i tested 4.6.1 and latest 4.9.2

[rikschennink]

@mverstegen Is the FilePond instance created when the collapse opens? and then destroyed when it closes?

[mverstegen]

Hi Rik, i load the different collapse items with ajax, then when all scripts are loaded from ajax call, i init the filepond.

I can send you har file over skype if you like. It always worked till a week ago i think. Nothing has changed on our side.

[rikschennink]

@mverstegen Please create a public test case on codesandbox.io, that makes it easier to debug.

[mverstegen]

I can't create a full sandbox for this, it goes wrong in my internal application, maybe we can do a screen sharing session?

⁣Verzonden door BlueMail ​

Op 17 dec. 2019 10:08, om 10:08, Rik notifications@github.com schreef:

@mverstegen Please create a public test case on codesandbox.io, that makes it easier to debug.

-- You are receiving this because you were mentioned. Reply to this email directly or view it on GitHub: https://github.com/pqina/filepond/issues/354#issuecomment-566450868

[rikschennink]

@mverstegen I really need to a public test case to debug this.

[ViniciusGularte]

Same problem here :hand:

Using Collapse Bootstrap crashes in chrome

My config

"filepond": "^4.6.1", "react-filepond": "^7.0.1", "chrome": 79.0

obs: Safari and Firefox not reproduce the crash

[marky291]

My setup works with.

"filepond": "^4.6.1", "vue-filepond": "^5.1.3",

Try back date each version and test your react to see which works.

[bloomedia]

Hi,

Same problem here. Chrome 79 crashes a few seconds after page is loaded, but at least on firefox works. I have these versions: "filepond": "^4.9.5", "jquery-filepond": "^1.0.0"

[mverstegen]

Hope someone has fixed this issue in the meanwhile and want to share his fix here. Rik asked me to setup a full public test case, but can't do that now. If someone can prove that this bug still exist and share a test case, i would be very grateful!

[rikschennink]

@webjohan created a demo here, and has a quick fix, any ideas/suggetsions are welcome.

https://github.com/pqina/vue-filepond/issues/121#issuecomment-576688283

[rikschennink]

So far I've only managed to prevent the "aw snap" by hiding the .filepond--root .filepond--drop-label element with display: none.

Note that this is not a fix, it's simply a debug result

Hiding the .filepond--root .filepond--drop-label label child doesn't fix it, which indicates to me the issue is related to the .filepond--root .filepond--drop-label element and not its children.

[mverstegen]

I added .filepond--root .filepond--drop-label{ display: none } to my css. Now the area for drag-and-drop images is very minimal and i can't drag images on it. When i add another css line after it like

.filepond--root *:not(text) { height: 30px; }

it shows same behaviour as before when i do something (open/close) with the collapse or hover over inspector code, whatever.

so for me it's even no quick fix. sorry. Firefox is working without problems.

[webjohan]

I think the drop-label is just the final thing in this perfect storm. Note that in my example the name on all 3 inputs is the same (yes on purpose). Giving the inputs unique names will make things better if I remember correctly. I will give full examples to morrow when I’m back on a larger screen then mobile.

[webjohan]

So back on a large screen again. It seems I was wrong, giving the input elements unique names doesn't stop chrome from crashing. Giving the filepond--drop-label element height is the trigger. One paint to many?

[rikschennink]

@webjohan The slide animation updates the height property which causes (A LOT) of reflows somehow Chrome bails out after a couple of times

I've forked the codepen here: https://codepen.io/rikschennink/full/WNbPQLj

It now animates every second. I can reproduce the issue consistently by trying to inspect the page:

Note that yesterday it took a bit more time, inspecting the body element worked, but then when hovering over elements in the inspector it would crash.

[webjohan]

One of my colleges ran chrome with logging and there was a GPU Cache error message which seems resonable when we're dealing with this many redraws. Still chrome should not crash. We also found that on his machine he had to trigger it by "refocusing" on the window, like you are doing when switching to the inspector tab.

[rikschennink]

@webjohan I think in your codepen this automatically happens because of all the clicks on the link.

[bjornarhagen]

I use the vanilla JS version 4.9.4 and it crashes with collapsible panels from Bootstrap.

I was seemingly able to fix the crashing by adding this CSS:

.panel-collapse.collapse .filepond--root,
.panel-collapse.collapsing .filepond--root {
    display: none;
}

.panel-collapse.collapse.in .filepond--root {
    display: block;
}

Not 100% sure though, the crashing is a bit inconsistent for me, but I haven't had a crash when the filepond input remain the same height.

[webjohan]

Filed an issue with the Chromium team: https://bugs.chromium.org/p/chromium/issues/detail?id=1044895

Not sure if "staring" the issue will help up the priority but ...

[rikschennink]

Alright, this is not ideal, but seems to be a temporary fix.

I tried setting different properties on the label container element but while setting display:none to the label worked, when adding a file to FilePond the aw-snap problem would return. This leads me to believe it has to do with the height of the FilePond root element, which is 0 when the label is hidden.

This seems to work. Wrap your FilePond in an additional element with a fixed height and an overflow hidden style.

See below for example applied to the @webjohan codepen, please confirm if this resolves the issue on your environment.

[webjohan]

@rikschennink this prevents chrome from crashing with my machine on codepen.

[webjohan]

Update: We might have discovered two Chrome bugs here. Looks like the chromium team is working on a solution.

[rikschennink]

@webjohan nice! Good stuff

[mverstegen]

Good work guys! @webjohan in special! @rikschennink your temp fix is working out for me as well.

[rikschennink]

@mverstegen Glad to hear that, thanks for confirming 😊

[webjohan]

Great news! The bug has been fixed in Chrome Canary 81.0.4042.0 and above

The Chromium team did a fantastic job!

[rikschennink]

@webjohan Waw! That is fast, didn't expect that to be honest. :-)

[webjohan]

@rikschennink I think they might have been working on a related issue for some time, but if not I'm super impressed ... still am though

[rikschennink]

will close as is chrome bug

[boulepick]

This is great that chrome is updating it's code to fix the issue, but what if the user has an outdated version of chrome, is there a workaround to fix this? Is the solution provided by "rikschennink commented on Jan 24" can be considered as a workaround?

[rikschennink]

@boulepick as it solves the issue, I believe so.

[boulepick]

thank you