Forms don't always submit on first attempt...?

[coastalrugs]

Just a ping to the community on their experiences or possible avenues to investigate.

I would say that about 30%-50% of the time, I need to hit 'Save Record' a second time while editing records in the Control Panel. If I don;t, the request eventually times out.

Questions:
- Where would my efforts best be spent investigating this; SC, my server's error log, etc?
- Has anyone else experienced anything like this? Is it systemic in SC or just 'my problem' (ie some configuration on my end)?

I can't say that I experience this behavior with any other system (or that cannot be pinned on some other cause), so it must be something with my server or the software installed on it.

Thanks for any input with this.

[coastalrugs]

Quick Update:

It appears that having 'Diagnostic Mode' toggled on, with the window open, helps alleviate the problem. So the issue is likely with a connection being dropped or changed, that the constant communication of the diagnostic window overcomes by keeping the line open.

I don't have any products or such that would require user uploads, but it does make me a bit weary knowing that posted data sometimes fails, for whatever reason. The above should work for Admin uploads, but customer uploads are still an unknown.

[Jamie]

I've had no other reports of this. Clicking the save record button does not require communication with your server in any way before the actual form submission is performed. We do call javascript to validate the form data prior to submitting the form.

I have no idea why you would be seeing that. You would need to debug the javascript that occurs when you click the button to determine if there is an actual problem causing the form to not submit.

[coastalrugs]

Thanks for the avenue of attack. I will report if/when I find anything definitive.

[coastalrugs]

Resolved...mostly.

This is what I have found:

+ The problem seems to only occur in Safari (I'm using OSX, can't validate in Windows, but I would imagine the same behavior is present, using the same rendering and execution engine)

+ It seems related to a long-standing communication bug in Safari/OSX that upon a redirect certain header information is missing. The short is that Safari (or some OSX library that Firefox does not use) seems to be the culprit.

+ It appears to be related to apache's keepalive time and when the form is submitted. Quick enough and form submits (under KA time), too long (more than timeout) and the connection resets and the form goes through. But the sweet spot in the middle, apparently that time between the 'keepalive' and 'timeout', causes the form submission to fail.

I withdraw the possibility of any issue that Squirrelcart expressly causes this trouble (though it may still be possible that a workaround that can be coded into SC for form submissions to not use keep alive connections).

What I did to make everything work on my end was to holistically disable keepalive for the index.php file inside the /squirrelcart/ folder with its own htaccess file:

<FilesMatch "index\.php$">
SetEnv nokeepalive
</FilesMatch>

This may not work for everyone.

(I wrapped in this conditional to focus attention on the problem file and not influence any other files. Though this still does not address the possibility of user-uploaded files failing in similar circumstances. But my situation does not have that possibility, so I am ignoring for now)

Speculation: Depending on the visitor load on one's store, one might be able to set the keepalive time and the timeout to the same value, which might close that hole altogether.


Something I did notice:
In the file: 'squirrelcart/includes/record_form/main.inc.php' on line 14 where the page's form is defined, you assign the form action to the php variable $SC['cart_www_page']. This variable does not appear to exist in this context, leaving the form action blank when editing records. While a blank action does post the page to itself, would it not be better to explicitly define the action to post to itself, either with index.php or a full path the the control panel page?

Additionally, I have always been told that when submit()ing a form it is good practice to include a 'return false;' in the onsubmit property to prevent the form from potentially submitting twice.

[Jamie]

Resolved...mostly.

Wow, that is a crazy problem. Glad you tracked it down.

Something I did notice:
In the file: 'squirrelcart/includes/record_form/main.inc.php' on line 14 where the page's form is defined, you assign the form action to the php variable $SC['cart_www_page']. This variable does not appear to exist in this context, leaving the form action blank when editing records. While a blank action does post the page to itself, would it not be better to explicitly define the action to post to itself, either with index.php or a full path the the control panel page?

That variable is no longer in existence. I'll get that changed to the proper constant.