Form.Serialize returning nada

Phil Petree

unread,

Oct 24, 2011, 5:18:26 PM10/24/11

to prototype-s...@googlegroups.com

Hey All,

Wierdness... I've not seen this before and I swear on my grandma's knickers this was working!

function dofill(url) {
var options = {
    method: 'post',
    parameters: $('myform').serialize(),
    onSuccess: fill_in,
    onFailure: ajax_err,
    on0: ajax_err
};
new Ajax.Request( url+".php", options );
}

The form header looks like this:

The form is NOT disabled and it has several hidden fields with data but when I inspect options before the call parameters is "" and when I verify/inspect the $_POST variable in php it's essentially empty...

Any clues as to why this would not work (or stop working)?

BTW, I'm using 1.6.1

Thanks!

ColinFine

unread,

Oct 25, 2011, 9:18:14 AM10/25/11

to Prototype & script.aculo.us

Your 'serialize()' is called when you _define_ dofill. Has the form
got any contents at that point?

Phil Petree

unread,

Oct 25, 2011, 9:40:59 AM10/25/11

to prototype-s...@googlegroups.com

Colin, thanks for taking the time to look. Yes, the form has some hidden fields with data (user must be logged in to access this particular form).

I found the problem... fixed it about 8 minutes ago, had to update the entire site!

The problem only surfaces under IE9. If you click into compatibility mode the problem goes away.

Our doctype WAS defined as:

<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Strict//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd">
<html xmlns="http://www.w3.org/1999/xhtml">

And the serialize failed.

I changed several things:

The doctype now reads:

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd">
<html>

Which in and of itself did NOT fix the problem.

So I forced compatibility mode using:

This solved the problem.

Backing back out to the original doctype with the forced compatibility mode and the problem resurfaced.

Maybe someone a whole lot smarter than me will be able to figure out a real solution for someone else! LOL

On Tue, Oct 25, 2011 at 9:18 AM, ColinFine <colin...@pace.com> wrote:

Your 'serialize()' is called when you _define_ dofill. Has the form
got any contents at that point?

--
You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group.
To post to this group, send email to prototype-s...@googlegroups.com.
To unsubscribe from this group, send email to prototype-scripta...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/prototype-scriptaculous?hl=en.

T.J. Crowder

unread,

Oct 25, 2011, 9:51:48 AM10/25/11

to Prototype & script.aculo.us

On Oct 25, 2:18 pm, ColinFine <colin.f...@pace.com> wrote:
> Your 'serialize()' is called when you _define_ dofill.

No, it'll get called each time he _calls_ `dofill`.
--
T.J. Crowder
Independent Software Engineer
tj / crowder software / com
www / crowder software / com

Victor

unread,

Oct 27, 2011, 10:57:24 AM10/27/11

to prototype-s...@googlegroups.com

Problem is somehow related to XHTML and IE9.

If you occasionally serve document as xhtml+xml, document should pass validation to work in browser. I've noticed <form name="..."> in your example, but name attribute is obsolete for form tag in XHTML1.0, or maybe you have   somewhere in your markup.

You can invoke $('myform').serialize() in debugger console at any time - this may reveal some clues.

Phil Petree

unread,

Oct 27, 2011, 12:30:27 PM10/27/11

to prototype-s...@googlegroups.com

obsolete attributes "should" be ignored. I used the form name attribute as a way of knowing which AJAX module to call on behalf of that form. That allows my dofill() to serve many forms.

I've seen very few pages of any type that validates 100% and browsers accomodate this and that's one reason why there are soo many differences in how browsers act on a given page.

In this case, it was working then we started getting complaints but they were intermittent and finally we were able to narrow it down to a problem we could duplicate and once duplicated it was easy to find (but harder to fix).

By changing the doctype, none of our pages will validate at this point but that's another issue that we'll fix in the next major release.

When I posted the original question we had no idea why form.serialize was failing and still dont think it should fail even if there was a $nbsp; somewhere in the field. form.serialize should process each field and if data is present, serialize it and if not skip it. A div or field with a space should not matter.

Like I said though, the key is not just in changing the doctype but you also have to force compatibility mode. This, to me, is a greater issue as it indicates a bug somewhere in either IE9 or prototype... but regardless of where it is, it causes prototype to fail.

--
You received this message because you are subscribed to the Google Groups "Prototype & script.aculo.us" group.

To view this discussion on the web visit https://groups.google.com/d/msg/prototype-scriptaculous/-/Kp0Uc3wWl2cJ.

Victor

unread,

Oct 27, 2011, 4:44:30 PM10/27/11

to prototype-s...@googlegroups.com

I used the form name attribute as a way of knowing which AJAX module to call on behalf of that form. That allows my dofill() to serve many forms.

This can be made via CSS classes, not name attributes.

I've seen very few pages of any type that validates 100%

1-2 errors/warnings does not matter. In your example EVERY tag is invalid for XHTML document.

and browsers accomodate this and that's one reason why there are soo many differences in how browsers act on a given page.

When document is [almost] valid (possibly with few errors/warnings), then there are actually very small differences between browsers.

we were able to narrow it down to a problem we could duplicate and once duplicated it was easy to find (but harder to fix).

Show minimal example, please. It is very interesting.

Like I said though, the key is not just in changing the doctype but you also have to force compatibility mode. This, to me, is a greater issue as it indicates a bug somewhere in either IE9 or prototype... but regardless of where it is, it causes prototype to fail.

Have you tried the latest Prototype 1.7?

Reply all

Reply to author

Forward