Odd form submit behavior in IE to a Perl CGI under IIS 6.0

radiantmatrix has asked for the wisdom of the Perl Monks concerning the following question:

I apologize that I can't provide much code, as the app I'm working on is proprietary. I am working on an application using CGI::Simple and HTML::Template; the whole thing works beautifully in Firefox. However, in order to get it to work in IE I have to shift-click the submit button.

I have attempted to search for this problem, but I don't really know what to call it. "Shift-click on form submit required in IE" and variations are all I've been able to think of, and the results have not been enlightening.

I've tried to reduce it to simple code that raises the issue, but without much luck. Debugging web scripts (e.g. with perl -d) is something I'm not real familiar with, so any tips there would be helpful as well. Essentially, I have a script which generates a form with a submit button named 'run' and itself as the form's action (POST method).

I have IIS set to expire all content immediately, so I wouldn't think this is a caching issue (but who knows, right?). My colleague working in ASP.NET on the same server isn't having these problems, so I figure it's either

something I'm doing wrong, or
something with CGI and/or the way the CGI system interacts with Perl

I'm using ActiveState Perl 5.8.4. Items worthy of note:

If I shift-click the Run button, everything works fine.
Extremely simple apps of the same general form work fine.
My full app generates XHTML 1.0 Strict code. It's been validated.
The script uses itself as the action target for the form.
This is IE-specific (works fine in Firefox), but I absolutely must have this working in IE -- corporate standards and all that.

If this turns out to be nothing to do with Perl, I'll be grateful (if annoyed, since IIS/IE experts aren't as readily available as my fellow Monks); but, if anyone can give me ideas about where I might be going wrong, places to look, etc., I will be thrilled.

I think I've given all the relevant information, but please ask if there's something I can tell you that will help. I will provide whatever I can short of breaching my NDA.

Thank you all in advance.

Update: thanks to Old Gray Bear, BaldPenguin, rlucas, and frodo72. Your ideas helped me find the culprit. The problem is actually two-fold:

When pressing "enter" to submit, IE doesn't like named submit buttons (unless they are named "submit").
My editor uses UNIX line-endings, and IE interpreted the HTML as all-on-one-line. I don't know why, but converting to Windows-style line endings solved half of the problem.

Once again, I'm stunned by the quality of the thoughtful, helpful, and timely response of the Monestary. Thank you all!

Yoda would agree with Perl design: there is no try{}

Comment on Odd form submit behavior in IE to a Perl CGI under IIS 6.0

Replies are listed 'Best First'.
Re: Odd form submit behavior in IE to a Perl CGI under IIS 6.0 by Old_Gray_Bear (Bishop) on Jun 02, 2005 at 23:12 UTC
I am currently working a simular problem -- a form that behaves one way on Firefox and another on IE6. (Brokenly in IE, an image object randomly positions itself over the text, the first time you load the page. A reload cleans up the problem, by the way.) The concensus of opinion here is that it is really a (known) IE bug, in the way that it renders XHTML. The local CSS Gurus have pointed me at something called "the 'quirks mode' in IE". It's triggered by "either the lack of a valid DOCTYPE/DTD or the presence of DOCTYPE on any line of the document after the first". It seems that IE6 is attempting to correct for a broken/missing element (created by early versions of MS Web-Authoring 'tools') and doing it badly. I spent most of this morning making test versions of my XML document stream and feeding them to the browsers. So far I haven't hit the right incantation, sigh. (XSLT really is a four letter word.) ---- I Go Back to Sleep, Now. OGB	[reply]
Re: Odd form submit behavior in IE to a Perl CGI under IIS 6.0 by BaldPenguin (Friar) on Jun 02, 2005 at 23:40 UTC
To second OGB's comment. I have found that while writing XHTML for IE that 'quirks' mode will give you nasty problems with things such a document.documentElement or document.getElementById. Also you cannot have an xml declaration on the first line, the first line MUST be the DOCTYPE, as noted above. Don WhitePages.Com	[reply]
Re: Odd form submit behavior in IE to a Perl CGI under IIS 6.0 by polettix (Vicar) on Jun 02, 2005 at 22:49 UTC
If I were you, I'd try to sniff traffic from the browser to the server and back, to see if the request is sent and what is it like. You could use a full-blown packet sniffer, like Ethereal with WinPCap, or a simple port redirector with logging (probably POE has something like this in its cookbook). I'd go with the first, but in Win32 you could (er - will) have problems sniffing packets in local, so be sure that the browser and the application are in distinct machines. Flavio (perl -e 'print(scalar(reverse("\nti.xittelop\@oivalf")))') Don't fool yourself.	[reply]
Re^2: Odd form submit behavior in IE to a Perl CGI under IIS 6.0 by Errto (Vicar) on Jun 03, 2005 at 03:06 UTC
If you're going this route I highly recommend HTTP::Proxy. It has saved me hours of headaches, and it's remarkably simple.	[reply]
Re: Odd form submit behavior in IE to a Perl CGI under IIS 6.0 by TedPride (Priest) on Jun 02, 2005 at 22:55 UTC
Try creating a copy of your script and having the first copy submit to the second copy. This will tell you if it's a caching problem (submit to self) rather than something else. If you still can't determine the problem, make a copy of your generated form, convert the proprietary text to gibberish, and post it somewhere where we can look at the page source.	[reply]
Re: Odd form submit behavior in IE to a Perl CGI under IIS 6.0 by rlucas (Scribe) on Jun 03, 2005 at 00:42 UTC
I strongly smell client-side (IE) issues here, not server, and definitely not Perl. (There is a chance that the server plays into it, such as by not faithfully rendering your expiration or nocache pragmas). I have two debugging suggestions: Can you put a changing token (such as e.g. a time() output) into a hidden form field and see if that changes things? When dealing with hard-to-uncover oddities such as this, I often find it is helpful to ensure that (at least second-by-second with the time() token) each transaction is indeed unique. This helps to cut down on cache-related fubars. Consider using javascript to capture onClick and onSumbit events to see what is happening. Simply doing onClick="alert('clicked')" or onSubmit="alert('submitted')" in the button and form, respectively, might clarify things and lead you on the path to more sanity. Good luck!	[reply]