August 4, 2010

Testing form submission locally in IE: an interesting bug/feature

A friend sent me a chunk of code with an inter­est­ing bug: on one par­tic­u­lar PHP script, IE would­n’t sub­mit the form. Every oth­er brows­er would. The first fix was rea­son­able, the sec­ond bizarre.

For the first fix, the offend­ing lines of code looked like:

   echo "<div class=\"form\"";   
   echo "<form action=\"index.php\" method=\"POST\">";

See it? The end of the first line does­n’t include a > to com­plete 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 attrib­ut­es to be con­sumed by the pre­vi­ous <div>. Not sure how we end up with an attribute called ‘<form’ at the end, but it could be a quirk of IE’s pars­er stack that will­ing­ly con­sumes garbage char­ac­ters and coerces them into attrib­ut­es. Nasty. This meant there was­n’t a <form> tag open so the sub­mit but­ton had noth­ing to do.

But that did­n’t fix it. I ripped out the con­tents of the form and test­ed; no. Ripped out the code before the form includ­ing the boil­er­plate; no (inci­den­tal­ly, if a <form> is the first tag in the code — eg. no <body> — then the <form> is dropped on the floor by the pars­er). Even­tu­al­ly I end­ed up with this testcase:

      <form action="index.php" method="post">
         <input type="submit">

Now at this point I was very, very con­fused. Dumb­found­ed. Espe­cial­ly since I’d looked at the file in hex-view to make sure strange Uni­code char­ac­ters had­n’t invad­ed then checked the encod­ing and BOM. I re-typed each line. Still did­n’t work.

I typed the con­tents out in a sep­a­rate file and copy/pasted over the top of the bro­ken one; still did­n’t work.

I copied the orig­i­nal file and opened the copy; still did­n’t work. I vis­it­ed ‘witch­craft’ on Wikipedia and researched human sac­ri­fice, per­formed a sacred rite involv­ing goats, 13-point stars and heavy breath­ing to the East; still did­n’t work.

I opened the prop­er­ties dia­log for the file on a whim:

Windows file properties dialog for the broken HTML form file

Were you aware that Win­dows auto­mat­i­cal­ly adds pro­tec­tion to a file that was trans­ferred from anoth­er PC, even if it was orig­i­nal­ly a .txt file? I cer­tain­ly did­n’t know it would dis­able form sub­mis­sion should the file be com­plete­ly renamed and opened in one par­tic­u­lar brows­er. Inter­est­ing. What kind of weird-arse check is being per­formed deep inside IE to do this? Is this relat­ed to why local AJAX does­n’t work?

I do see the point of this; Unknow­ing User #523 is sent a file and told to rename and open it in IE to receive a free pay­ment of five mil­lion Niger­ian pan­das or some­thing, and JS auto-sub­mits a form con­tain­ing infor­ma­tion from their machine. But what’s the dif­fer­ence between this file being on a web­site or run­ning local­ly? JS should­n’t have high­er priv­i­leges, and there’s no local-file access apart from <input type=‘file’>, and a file con­trol’s val­ue can’t be set in HTML or JS auto­mat­i­cal­ly. Is this a pro­tec­tion against secu­ri­ty bugs in the brows­er that the shell team devel­oped, which then required obscure changes to IE’s code­base any­way? Urgh.

Long sto­ry short: if your oper­at­ing sys­tem is doing funky, hid­den stuff to files that make them break in com­plete­ly unre­lat­ed sit­u­a­tions, show a bloody mes­sage some­where. IE6 gave us the yel­low bar when JS was dis­abled for local files — ter­ri­bly annoy­ing and arguably point­less, but at least it was a mes­sage. This is just arcane.

posted by Andrew

Leave a Reply

Your email address will not be published. Required fields are marked *