Google Toolbar AutoFill is Weird
NOTE: This article is out of date and likely obsolete.
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.
So I started checking other forms, and noticed that on the comments field here in WordPress, it fills in the wrong fields! It shows the email and website fields as being fillable (AutoFill doesn’t have a spot to provide a website). Worse, it fills in your name as in the email field, and your email address as your website!
At this point, I figured I’d read the search hit called Google Toolbar Autofill quirks. The author did some investigation and found that “it apparently looks at a text box and then tries to backtrack from that location looking at text.” In other words, instead of looking at the field’s name, or the content of an explicitly-associated label, it looks to see what text appears before it. This is…a bad design. It makes sense as a fallback measure, but you don’t start with the heuristics when you have more reliable indicators that you can check just as easily!
It broke on the first contact form because, despite the fact that the field was called “name,” the label said “Your Name.” I pulled out the word your and it recognized it. Strangely, it was perfectly happy with anther form which had a field labeled, “Your Full Name.”
It broke on the WordPress comment form because the Kubrick layout puts the labels to the right of the fields. The fields and labels are paired within lines—in fact, each field/label pair is its own paragraph. So you’d think that some text in the same paragraph would be more closely associated with the field than some text in an earlier paragraph. Plus, each field has a <label>
tag, so there should be no ambiguity as to which label applies to which field!
A more sensible approach would be this:
- Check the field name, as in…
<input type="text" name="email">
This is where ECML says to look, after all! If it matches your list, use it and do not continue to step 2; no one is going to ask people to fill out “Ecom_ShipTo_Postal_City.” - Check for an explicit label, as in…
<label for="myfield">E-mail</label> <input type="text" name="indecipherable" id="myfield">
If it matches, use it. If you find a<label>
for the field, even if you can’t use it, do not continue to step 3. The page’s author has already told you what the field is called, and you’ll either get the same label or something irrelevant. - If those both fail, check the text immediately before and after. Figure out which is more closely associated. (Hint: If some text is on the same line, and some isn’t… the text on the same line is probably attached to this field!)
I’ll rename the “Your Name” field in the first form, and I’ll tweak any other pages I find having problems, but I’m just plain annoyed at the spectacular failure on the WordPress form.
For future reference, this behavior was observed with the Google Toolbar for Firefox version 2.0.20060515W. The WordPress comment form in question is from the WordPress 2.0 version of the Kubrick theme, modified only slightly (I changed the “URI” label to “Website,” since more people will know what it means).
Jas Shephard
Maybe a little late but I have confirmed your finding. Also I have found that if you break the address up by say, having the address fields in the 2 lefthand columns of a table and other non-related labeled texts fields in the 2 right hand columns, the the address breaks. It seems to scan forward for the zip code field to recognise the preceeding fields as part of an address.
Second point, if you put two identical address fields on a page it fills the second one in with the alternative address. Weird as you say. Autofill pays no attention to RFC3106, contrary to what the Google advice page states.