Because of the way the name and address fields are named in the checkout form, the browser autocomplete (at least in Chrome) puts the address in the name field and doesn't autocomplete in the address field. I'd suggest renaming these fields so they don't have address[und][0][name] etc. as the field names. Even if it means you don't have a nested array in $form_state['values'], I think the user experience outweighs whatever convenience that provides on the backend.

Support from Acquia helps fund testing for Drupal Acquia logo

Comments

Damien Tournoud’s picture

Project: Commerce Core » Address Field
Component: User experience » Code

Thanks for your report. This is indeed something we should keep an eye on.

In my limited testing, and browsing through the Chromium source code, it seems that this field should contain 'full_name', the nested form structure doesn't matter.

rszrama’s picture

Title: Naming of checkout name/address fields prevents browser autocomplete from working correctly » Rename form elements to improve browser autocomplete functionality
Category: bug » feature
Status: Active » Postponed

Not sure we really wanna go renaming stuff this late in the game. I haven't had any issue with autofill on Chrome. Will need browser / OS info to be able to test this, but I'm hesitant to consider making the change at all.

perusio’s picture

We could add this at the theme layer. Here's an example: https://gist.github.com/perusio/5525315.

neochief’s picture

Status: Postponed » Needs review
FileSize
4.85 KB

Here's the patch which solves this without changing the field names (based on parusio's lead).

Successfully tested it in Chrome and iOS7 Safari (iPad). It also works with Last pass extension in all browsers.

neochief’s picture

Can somebody test it in MacOS Safari? In my case it gave totally weird result: it filled all the address fields just fine, but city and state got the full address line values. Maybe it's just a glitch in my case, I'd like to be sure.

Even if it doesn't work, I think it's rather bug in Safari, since iOS Safari fills fields perfectly.

neochief’s picture

Here's the better one, which supplies correct values for full name and organisation name.

rszrama’s picture

Issue summary: View changes
Status: Needs review » Fixed

Tested and confirmed that Google Chrome now finally autocompletes my name and address at the same time. Thanks for the patch!

Commit: http://drupalcode.org/project/addressfield.git/commitdiff/7b5bd39

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.

j0rd’s picture

Question about perhaps this patch causes problems with regards to lowercase vs uppercase and countries and states (if you're using "select"'s for those)

I have a lot of problem recently since upgrading which I've never noticed before, which look like this.

// I have hundreds of these
2014-02-16 19:27	Illegal choice ap in State element.	Anonymous (not verified)	
2014-02-16 19:09	Illegal choice at in Country element.	Anonymous (not verified)	
2014-02-16 19:09	Illegal choice ms in State element.	Anonymous (not verified)	
2014-02-16 18:46	Illegal choice it in Country element.	Anonymous (not verified)	
2014-02-16 18:46	Illegal choice ne in State element.	Anonymous (not verified)

Notice all the states and countries are in lower case.

This is leading me to believe this patch may be causing this by pre-filling in lower case entries. Else something else is going on in my install which is possible. But I figured I'd post here, since I know it's something along these lines which has changed.

You should be able to find these problems in your dblog by filtering for "form" module.

Code in question which causes these errors is here (isset() is case sensitive):

          foreach ($value as $v) {                                                                                
            if (!isset($options[$v])) {                                                                           
              form_error($elements, $t('An illegal choice has been detected. Please contact the site administrator.'));                                                                                                             
              watchdog('form', 'Illegal choice %choice in !name element.', array('%choice' => $v, '!name' => empty($elements['#title']) ? $elements['#parents'][0] : $elements['#title']), WATCHDOG_ERROR);                         
            }                                                                                                     
          }                                                                                                       
        }                                                                                                         

Lucky for me I have this on my registration form, so I believe I'm losing hundreds of signups :) ... but not sure if this patch is the problem or not yet.

ALSO: Keep in mind, i assume browsers will attempt to pre-fill previous entries from other websites, where those entries might not match up to the input addressfield expects.

j0rd’s picture

Update: I added UA tracking to the dblog and it appears all the browsers (5 so far) are Chrome 28.x

Here's the UA's from the 5 IPs I tracked with failed form submissions since I added tracking last night:

(Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36)
(Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.72 Safari/537.36)
(Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36)
(Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36)
(Mozilla/5.0 (Windows NT 6.2; WOW64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/28.0.1500.71 Safari/537.36)
rszrama’s picture

Status: Closed (fixed) » Needs review

I'm on Chrome and haven't noticed any issues, but I'll see if I can reproduce it. Maybe it requires me to fill a form first somewhere that just uses a textfield for state / province and save an address with lower case values?

bojanz’s picture

Status: Needs review » Fixed

I've committed an update in #2454591: Update autocomplete attributes for latest standard which removes the x-autocompletetype attributes and implements the latest version of the autocomplete attributes,
as described in https://html.spec.whatwg.org/multipage/forms.html#autofilling-form-contr... and provided by Chrome's dev console.

Since the autocomplete implementation in Chrome (and probably other browsers) changed multiple times, let's retest and open new issues for any encountered problems.

Status: Fixed » Closed (fixed)

Automatically closed - issue fixed for 2 weeks with no activity.