- redballoonfamilyAsked on March 29, 2014 at 08:32 AM
I have created a form so that parents can order photographs of their children in a recent play that two of our drama groups performed in.
However, in Internet Explorer & Firefox, every time I try and test it (on different machines) the form crashes.
Could you please advise as to what the problem is. If its because there are too many available products, should you note somewhere on the PayPal integration that there's a maximum before the system overloads?
If there is a better way of organising the form so it does not crash the system, please advise what this is. I've had an excellent experience of Jotform so far and would hate to have to move to another data collection and payment solution if your forms cannot handle this kind of submission.
- JotForm SupportEltonCrisAnswered on March 29, 2014 at 05:16 PM
I was able to reproduced it with Firefox but not with Chrome. It's obviously due to the huge sub product options you have on the form. This causes the browser script to malfunction due to a huge process required. Unfortunately, I have no idea how to get this resolved as of now except when you reduce your sub-product options. It's probably the best way rather than forcing the user to use different browsers which is not their expectation.
Let us know if you have further questions. Regards!
- redballoonfamilyAnswered on March 30, 2014 at 12:07 PM
Thanks for getting back to me. To be honest, you haven't told me anything I didn't already know although maybe I phrased my question wrong.
What's maximum amount of sub-product options you can include before you start encountering problems like this? As I said in my previous query, is it worth noting somewhere on the PayPal integration that too many options will cause buggy performance and crashes?
Does the overload happen at 100 options? 50? 10? I'd rather not have to muck about trying all different combinations - if you could give me a figure that would be helpful... (and make this info available to others as I can't imagine I'm the only one who's encountered this).
Is there a way of reducing the processing overhead of the product options? Perhaps this is worthy of one of your many widget add-ons that are being produced ten to the dozen at the moment?
- JotForm SupportjonathanAnswered on March 30, 2014 at 04:12 PM
What's maximum amount of sub-product options you can include before you start encountering problems like this?
There is no known limitation or even documented known limitation. If you noticed already, you can add as many as you want when designing the form or on the form builder.
You can reduced the overhead process by using the form's source code embed
When you used the form's source code embed, the form will become locally located to the host web server it will be embedded.
Unlike when using only script embed, the form is located remotely to JotForm. So, fetching form such us your form, will take up huge overhead in network bandwith spike when can also cause chrashing of the browser.
Perhaps you can try also embedding the form using its source code, then observe if it makes the difference.
- redballoonfamilyAnswered on March 31, 2014 at 12:44 PM
Thanks for the suggestion but it didn't work - crashed all the same even when using source code embed (both versions).
So I'll have to design something else where the user has to do the adding up at the checkout themselves. Less than ideal but the only way I can think of making it work...
- JotForm SupportTitusNAnswered on March 31, 2014 at 01:57 PM
Sorry about that -
I recreated your original form, and forwarded the issue to our developers for further counsel.
We will be adviced on the limitations of the payment fields on this thread.
In the meantime, we would love to help you out with your alternate solution - using our form calculation widget, a lot can be achieved - Even using checkboxes and drop-down lists.
Please tell us what you want to achieve in a new support thread by clicking here and we will assist as much as possible.
- JotForm SupportNeilVicenteAnswered on April 05, 2014 at 06:54 AM
We have reduced the overhead of the subproducts calculation. Your form should now be able to have that many subproducts without crashing the browser.
Still, we suggest that you keep it to a minimum, preferably around 200, as there may be users who have slower computers.