August 4, 2010
Testing form submission locally in IE: an interesting bug/feature
A friend sent me a chunk of code with an interesting bug: on one particular PHP script, IE wouldn’t submit the form. Every other browser would. The first fix was reasonable, the second bizarre.
For the first fix, the offending lines of code looked like:
echo "<div class=\"form\""; echo "<form action=\"index.php\" method=\"POST\">";
See it? The end of the first line doesn’t include a > to complete the <div> tag. The result in IE’s DOM:
<div class="form" method="POST" action="PRMT_process.php" <form="">
The lack of a > caused the <form>‘s attributes to be consumed by the previous <div>. Not sure how we end up with an attribute called ‘<form’ at the end, but it could be a quirk of IE’s parser stack that willingly consumes garbage characters and coerces them into attributes. Nasty. This meant there wasn’t a <form> tag open so the submit button had nothing to do.
But that didn’t fix it. I ripped out the contents of the form and tested; no. Ripped out the code before the form including the boilerplate; no (incidentally, if a <form> is the first tag in the code — eg. no <body> — then the <form> is dropped on the floor by the parser). Eventually I ended up with this testcase:
<body>
<form action="index.php" method="post">
<input type="submit">
</form>
</body>
Now at this point I was very, very confused. Dumbfounded. Especially since I’d looked at the file in hex-view to make sure strange Unicode characters hadn’t invaded then checked the encoding and BOM. I re-typed each line. Still didn’t work.
I typed the contents out in a separate file and copy/pasted over the top of the broken one; still didn’t work.
I copied the original file and opened the copy; still didn’t work. I visited ‘witchcraft’ on Wikipedia and researched human sacrifice, performed a sacred rite involving goats, 13-point stars and heavy breathing to the East; still didn’t work.
I opened the properties dialog for the file on a whim:
Were you aware that Windows automatically adds protection to a file that was transferred from another PC, even if it was originally a .txt file? I certainly didn’t know it would disable form submission should the file be completely renamed and opened in one particular browser. Interesting. What kind of weird-arse check is being performed deep inside IE to do this? Is this related to why local AJAX doesn’t work?
I do see the point of this; Unknowing User #523 is sent a file and told to rename and open it in IE to receive a free payment of five million Nigerian pandas or something, and JS auto-submits a form containing information from their machine. But what’s the difference between this file being on a website or running locally? JS shouldn’t have higher privileges, and there’s no local-file access apart from <input type=‘file’>, and a file control’s value can’t be set in HTML or JS automatically. Is this a protection against security bugs in the browser that the shell team developed, which then required obscure changes to IE’s codebase anyway? Urgh.
Long story short: if your operating system is doing funky, hidden stuff to files that make them break in completely unrelated situations, show a bloody message somewhere. IE6 gave us the yellow bar when JS was disabled for local files — terribly annoying and arguably pointless, but at least it was a message. This is just arcane.