Bug 172533 – Camera/Canvas file input crash: A Problem Occurred with this Webpage so it was Reloaded

• Status: RESOLVED
• Resolution: WORKSFORME
• Component: Canvas

[zac spitzer]

When taking a photo using HTML file input with an iPhone, Safari often crashes cryptically 
with the "A Problem Occurred with this Webpage so it was Reloaded". It seems this is due 
to an out of memory error, crash logs include reason:vm-thrashing

It may be related to canvas resizing, as the captured image, especially with 
the iPhone's higher megapixel camera producing much larger files that usually 
need to be resized before uploading

I did some research on github and people have been experiencing similar problems

https://github.com/kobotoolbox/enketo-express/issues/398
https://github.com/scottcheng/cropit/issues/226
https://github.com/Foliotek/Croppie/issues/243

this blog post goes into a lot of detail about this problem
http://digitalservicescompany.com/blog/case-study-image-resize-in-a-browser/

[Simon Fraser (smfr)]

What iOS versions and which iOS devices show the problem?

[zac spitzer]

Been seeing this problem occur on a iPhone 6 running 10.3.1, one user dropped back to an iPhone 5 with 10.3.1 and it didn't happen for a while, but then it started happening again. I can't reproduce this on an iPad (guessing due to smaller camera)

It was also happening with 9.3.x

[Radar WebKit Bug Importer]

<rdar://problem/32383118>

[zac spitzer]

another crash example
https://github.com/kangax/fabric.js/issues/3693

[Simon Fraser (smfr)]

I filed bug 172728 about https://github.com/kangax/fabric.js/issues/3693

[Simon Fraser (smfr)]

It would be helpful to provide URLs where the issues reported in the links in the first comment can be reproduced.

After analyzing https://github.com/kangax/fabric.js/issues/3693 in some detail, I believe it's not directly related, unless all the other sites are using the fabric canvas library.

[zac spitzer]

I just reproduced the crash on the "Upload Example (with exif orientation compatability)" demo here http://foliotek.github.io/Croppie/ (near the bottom of the page)  with an iPad running 10.3.2, you need to take quite a few photos (sorry I didn't keep an exact count!) and then it reloads

[zac spitzer]

this also crashes after taking 5 photos http://scottcheng.github.io/cropit/ using the first demo on the page, iPad 10.3.2

[Simon Fraser (smfr)]

Thanks, I'll try those.

[Simon Fraser (smfr)]

(In reply to zac spitzer from comment #8)
> this also crashes after taking 5 photos http://scottcheng.github.io/cropit/
> using the first demo on the page, iPad 10.3.2

Do you mean that you tap the "Choose File" button once, take a photo, and then take 4 more photos using the "Retake" button in the camera UI? Or something else?

[Simon Fraser (smfr)]

(In reply to zac spitzer from comment #7)
> I just reproduced the crash on the "Upload Example (with exif orientation
> compatability)" demo here http://foliotek.github.io/Croppie/ (near the
> bottom of the page)  with an iPad running 10.3.2, you need to take quite a
> few photos (sorry I didn't keep an exact count!) and then it reloads

I reproduced it here. Thanks!

[zac spitzer]

another similar problem with some detailed investigation via xcode
https://github.com/mapbox/mapbox-gl-js/issues/4695#issuecomment-305304043

[Simon Fraser (smfr)]

Interesting but let's not pile everything onto this bug. Please file a new bug for https://github.com/mapbox/mapbox-gl-js/issues/4695

[Krister Bäckman]

Happens on iOS 9.3.5 as well

[Simon Fraser (smfr)]

http://foliotek.github.io/Croppie/ creates a 3024x4032 canvas, which is 418MB, which is one reason why the web process gets killed.

[Simon Fraser (smfr)]

http://foliotek.github.io/Croppie/ also has an <img clas="cr-image"> with a 3D transforms and a 1280 x 720 image, which creates a layer of 2x or 3x that size (depending on device resolution), which also eats a lot of memory. So I think the http://foliotek.github.io/Croppie page is just using too much memory for images, layer backing store and and canvas.

[Simon Fraser (smfr)]

http://scottcheng.github.io/cropit/ is also very memory hungry, with <img class="cropit-preview-background"> taking 209MB, and <img class="cropit-preview-image"> taking 188MB.

[zac spitzer]

But they work first time, why does it crash only after several attempts?

[Simon Fraser (smfr)]

I haven't figure that part out yet :)

[zac spitzer]

Sorry to pester, but any progress on this? 

I have some very frustrated clients who are contemplating buying Android devices

[Dean Jackson]

(In reply to zac spitzer from comment #20)
> Sorry to pester, but any progress on this? 
> 
> I have some very frustrated clients who are contemplating buying Android
> devices

Nothing to report yet. We'll get to it soon.

[zac spitzer]

any updates? so many developers are battling against this bug and wasting hours trying to find workarounds

[Simon Fraser (smfr)]

In my investigations, this was mostly caused by web pages creating very large canvas elements (or leaking canvases, in the case of Fabric.js). If this affects your content, the best option is to optimize canvas memory usage.

[zac spitzer]

So why is this only a problem with Safari and only after processing several images via canvas? 

I've been using https://github.com/gokercebeci/canvasResize and have tried manually setting every canvas object to null, but Safari still just runs out of memory and crashes

Neither Chrome or Firefox on Android exhibit this problem?

Is a Native API for image resizing needed? Modern cameras produce really large images and they need to be down sized before being uploaded and currently Canvas is the only option

[Bobby]

Its crashing for we without canvas being used, just a pure JS target.files and POST with payload in the body. iPhone 8, iOS 12.1

[Bobby]

(In reply to Bobby from comment #25)
> Its crashing for we without canvas being used, just a pure JS target.files
> and POST with payload in the body. iPhone 8, iOS 12.1

Now tested with iOS 12.1.4, same crash. Photo size from 1.6meg to 2.4meg. First photo almost always works, subsequent photos consistently crash (second, third)

[Simon Fraser (smfr)]

(In reply to Bobby from comment #26)
> (In reply to Bobby from comment #25)
> > Its crashing for we without canvas being used, just a pure JS target.files
> > and POST with payload in the body. iPhone 8, iOS 12.1
> 
> Now tested with iOS 12.1.4, same crash. Photo size from 1.6meg to 2.4meg.
> First photo almost always works, subsequent photos consistently crash
> (second, third)

Do you have a URL we can test with?

[Alban Seurat]

I have the same issue with my iPhone 8 with iOS 12.4.1

Any website using <input type=file> is crashing safari after 2 or more takes (probably depending on the memory availability at the time. 

You can simply try to take several photos (without submitting them) there for instance: 
https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_accept

[Said Abou-Hallawa]

I tried the following links 

https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_accept
http://scottcheng.github.io/cropit/
http://foliotek.github.io/Croppie/

On iPad Air 2/trunk webkit and I could not reproduce the crash after taking at least 10 photos.

[Said Abou-Hallawa]

I will try these scenarios on iPhone 6 Plus which is more memory restricted.

[Said Abou-Hallawa]

On iPhone 6 Plus/iOS 14/Trunk WebKit, I was able to take over 20 photos with the following pages:

https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_accept
http://foliotek.github.io/Croppie/

And no crashes happened.

[fnicolicds]

Seems that this issue is still happening on iOS 15. I was able to make the web content process crash just by taking photos (around 40) on my iPhone X iOS 15.4.1 with the following page: https://www.w3schools.com/tags/tryit.asp?filename=tryhtml_input_accept