I briefly enabled the Google Toolbar to check some PageRank stats, and noticed some fields on contact forms were highlighted in yellow. A little experimentation revealed that this was part of the toolbar’s AutoFill capability, which will try to identify standard form fields and fill in your name, address, etc. (There’s a config box where you fill it all in once.)
The weird thing was that this form had name and e-mail fields, but AutoFill only recognized e-mail. I figured, OK, people might be using this, let’s see if I can adjust the page and make it compatible.
This form was using “name” and “email” for the actual names of the fields. They were labeled “Your Name” and “E-mail,” in separate table cells before the fields, with explicit <label> elements. A bit of searching turned up the fact that AutoFill looks for field names defined in ECML (RFC 3106). That list applies to the actual field names, not the visible labels, and if I’m reading it correctly, both “name” and “email” should work. Continue reading →
Today I was trying to fix a problem in a section of a website that hadn’t been changed in roughly 5 years. The page in question retrieved data from a database and filled out an Acrobat form using FDF. Under some circumstances, Adobe Reader would generate an error message, “Expected a dict object.” Then it would freeze, and crash the web browser for good measure.
This site was built with ColdFusion, and used a then-freely-available library called PDFFormFiller.cfm (I can’t find any sign of it now) to generate the FDF code. After saving the offending FDF to a file (eliminating the browser as a factor), I started manually editing the code to see what happened.
The problem turned out to be parentheses appearing in the form data. FDF uses parentheses-delimited strings, and it was finding ) in the code and trying to parse what was left as FDF tokens. The solution was simple: just escape the parentheses as \( or \). Continue reading →