Skip to content

HTTPS clone URL

Subversion checkout URL

You can clone with HTTPS or Subversion.

Download ZIP

Loading…

Form model doesn't update on autocomplete #1460

Closed
msgilligan opened this Issue · 198 comments
@msgilligan

I'm having problems with Safari 6.0 auto-complete on some simple forms
on Angular 1.0.2.

When Safari uses auto-complete to fill in the form, Angular seems to be
unaware of the new characters that were entered by auto-complete.

Please see the attached image for an example.

To reproduce:
1) Enter data into the form a few times so that auto-complete is activated.
2) Then enter a few characters that triggers an auto-complete.
3) Hit return.
4) Compare the alert message with the contents of the input field.

I've created a jsFiddle that can be used to reproduce the problem:
http://jsfiddle.net/msgilligan/5cynT/

I've seen a similar problem when Safari 6.0 or Chrome 22.0.1229.79
automatically fills in a password field that has a 'required'
attribute. The form is not marked as valid and I have to go enter a
space after the password and then delete it.

@msgilligan msgilligan closed this
@msgilligan msgilligan reopened this
@bigbag

A similar problem and Firefox 15.0.1

@sudhirj

How would you handle this? At glance it looks like the browser isn't firing change events if the form is being populated via autofill. The first thing I can think of is to run periodic checks on the form, but that sounds very suboptimal.

@GEverding

Has anymore thought gone into this issue?

@pgte

Any insights on this one?

@bigbag

Just banned completion. But this does not solve the problem

@davemerrill

+1 for effort towards some sort of solution.

@fedotxxl

+1. Pls fix this

@mgoku

I switch from Knockout to Angular just to find that it has the same issue with form autocompletion.

@sweinertjr

+1 fix please. :(

@shmuel613

+1 Please fix!!!!!

@sophlee

+1 Please fix it :(

@lucassp

Any progress? +1

@davemerrill

The underlying problem I think is that browsers don't (always? ever?) emit any sort of event on auto-complete, as Witold said in this thread: https://groups.google.com/forum/?fromgroups=#!topic/angular/6NlucSskQjY. Other than periodically checking the value in every field that might auto-complete, I bet this is on browser makers to fix, not Angular.

@shmuel613

Dave, I understand what you're saying, but Angular still needs to come up with an integrated solution. The reason is that form validation coupled with disabling submit buttons renders the page unusable without special controllers listening for user actions. One solution could be to re-validate the forms automatically after page load, but unfortunately, I haven't found a way to re-fire the validation that way.

@drphrozen

I have the same issue on Chrome 25 on Win7. I found it from this issue: #1072 which also provides a temp fix.

@johannesjo

+1 Temp fix doesnt work for more complex cases (e.g. a select contains a object as model).

@RWOverdijk

+1... This is a very annoying issue. (Login forms should autofill. Now I can't let them be autofilled.)

@augustl

I would say the underlying issue is that browsers assumes the form will be submitted in the traditional manner, i.e. the field values will be read upon form submit.

The best fix I can think of is to have a method in AngularJS for reading out ng-model bound values when the form is submitted. Perhaps this could be a generic feature of scopes, such as $scope.$read(), which would be implemented so that ng-model on forms would actually read the .value when this method was called.

@augustl

Here's an example of a very (!) simple and small ng-model implementation that allows for getting the values on demand. Simply $scope.$broadcast("$myNgModelSet") and the model will be updated.

App.directive("myNgModel", ["$parse", function ($parse) {
  return {
    restrict: "A",
    link: function ($scope, $element, $attrs) {
      // Assume $element is input type="text"
      var modelGet = $parse($attrs["ngModel"]);
      var modelSet = modelGet.assign;

      function setValueFromInputElement() {
        modelSet($scope, $element.val());
      }

      $scope.$watch($attrs["ngModel"], function () {
        $element.val(modelGet($scope));
      });

      $element.bind("change", function () {
        setValueFromInputElement();
      });

      $scope.$on("$myNgModelSet", function () {
        setValueFromInputElement();
      })
    }
  }
}]);
@mike-spainhower

Chrome at least does indeed emit an event (https://code.google.com/p/chromium/issues/detail?id=135307), so I think there is a legitimate issue here.

In addition to a fix for the issue, it would be great to have a sanctioned workaround for browsers that do not emit an event which is explicitly forwards-compatible.

@RWOverdijk

Like a timeout of some sort specifically for forms. Or at least a way to tell angular to re-check.

@whuhacker

+1 Please fix this.

I am using a temp hack which is quite dirty:

    $('#my-form input:visible, #my-form select:visible').each(function(){
        $(this).trigger('input');
    });

However, this will trigger another problem. I always got the following errors in concole:

    Error: $apply already in progress
    at Error (<anonymous>)
    at beginPhase (http://ajax.googleapis.com/ajax/libs/angularjs/1.0.5/angular.js:8270:15)
    at Object.Scope.$apply (http://ajax.googleapis.com/ajax/libs/angularjs/1.0.5/angular.js:8072:11)
    at HTMLInputElement.listener (http://ajax.googleapis.com/ajax/libs/angularjs/1.0.5/angular.js:11421:13)
    at HTMLInputElement.jQuery.event.dispatch (http://ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.js:3058:9)
    at HTMLInputElement.elemData.handle.eventHandle (http://ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.js:2676:28)
    at Object.jQuery.event.trigger (http://ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.js:2941:12)
    at HTMLInputElement.<anonymous> (http://ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.js:3599:17)
    at Function.jQuery.extend.each (http://ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.js:611:20)
    at jQuery.fn.jQuery.each (http://ajax.googleapis.com/ajax/libs/jquery/1.8/jquery.js:241:17) angular.js:5687
@drphrozen

whuhacker You need to call your hack outside of angular. . Try setTimeout(function() { ... }, 0)
Sorry about the format, doing this with my mobile and SwiftKey.. It's not code intelligent :-)

@stephenh

@mike-spainhower I believe that bug report is for a different type of auto-fill than a "remember password" type auto-fill.

I've filed a new bug against Chrome here:

https://code.google.com/p/chromium/issues/detail?id=224405

Which links to a JSFiddle that shows the "Remember password" auto-fill does not trigger a change event.

@mike-spainhower

@stephenh Touche! I knew that they were separate under settings but did not realize autofill and passwords had separate behavior - great catch.

Is it still fair to say that angularjs users still need a consistent and supported way to get expected behavior across browsers and versions? From what I gather the closest we have to this currently is setting autocomplete attribute to off.

@stephenh

@mike-spainhower I agree, that "regular autofill" and "password autofill" is different behavior was surprising to me too.

I think @whuhacker has the best hack for Chrome right now.

For Firefox, it is working for us with this change to Angular:

stephenh@f6295cc

If anyone wants to use/clean up/submit that patch, please feel free.

I haven't gotten to trying anything other than Firefox/Chrome--Chrome is being so annoying about this that I'm giving up for awhile and will try again later with a fresh set of eyes.

@drozzy

Angularjs also does not work with LastPass auto-fill.

@stephenh

@drozzy How does LastPass auto-fill work? It should either a) fill in the values before body.onload runs (in which case my patch to Angular should fix it, like it did Firefox), or b) fill in the values after body.onload and fire a change event (in which case it should just work, so maybe they aren't firing an onchange).

@drozzy

@stephenh I don't know... But it doesn't work even if I manually click "autofill" AFTER the page has loaded, through the right-click context menu...

@stephenh

@drozzy Sounds like a bug in LassPass then--they should fire a change event when they do that, and then Angular will pick it up.

@eliasdawson

We're also encountering this problem with our app. With LastPass and SuperGenPass, the fields are populated, but the scope isn't updated so when the form is submitted the data passed to our API doesn't match what the user entered. In addition .change() and .trigger(input) or scope.$apply do not result in an updated scope. I suspect because the model doesn't think the data changed, but I don't know. Only solution I've found that has worked is to manually set the scope with jQuery val in the submit angular submit handler which completely overrides the data-binding, and doesn't address the actual issue.

@mkelley33

+1 Login forms should autofill.

@eliasdawson

I came up with a better solution than my previous, but that's not saying much and it doesn't solve the main issue and may well have problems I haven't considered. In my submit handler, I update the value of each input with it's current value using $setViewValue:

$( 'input[ng-model], select[ng-model]' ).each( function() {
  angular.element( this ).controller( 'ngModel' ).$setViewValue( $( this ).val() );
});
@psi-4ward

+1 works with no form-fill plugin

@arikal

I urgently need a fix or elegant workaround for this. This issue makes angular.js's two-way data binding paradigm fundamentally flawed.

@arikal

Changing the event which triggers the model update seems to remedy it:

arikal/angular.js@3040148

@arikal

YUI has a solution in its own framework - implementing its own event:

http://yuilibrary.com/yui/docs/event/valuechange.html

@davemerrill
@arikal

From what I've seen, currently only input events trigger a scope update, but autofill implementations tend to trigger the change event. I'm not sure what the reasoning behind using input over change is - maybe somebody can shine some light on this?

@Swader

+1 this is essential and it's ridiculous that this issue has been opened for 7 months now. Please fix asap.

@symblify

Pull request #2129 may well be a solution to this issue, as it allows additional or alternative events to trigger updates.

@cmygeHm

Pull request #2129 is a solution, but it's hack, it's not normal behavior for framework.

@IgorMinar
Owner

Guys, I find it really sad when you say things like "it's ridiculous that this issue hasn't been fixed yet". If you really cared about this issue, you'd fix it already and submitted a patch. Accusing others of lack of action when you are not doing anything either is ridiculous.

Having said that, nobody on this thread actually mentioned that this is a weird browser/spec issue that is caused by the input event not being fired upon autofil/autocompletion. Has anyone actually tried to figure out what event should we listen on in order to get notified of the new value? I've seen only one comment suggesting that change event might be the right one to listen. But if you ever worked with the change event you'd know that it's not a great choice in many other situations. So as you might have guessed the solution is not trivial and it needs to be well tested. Does anybody want to step up and offer a proper fix?

@IgorMinar
Owner

oh.. so maybe the change event doesn't work so well.. http://furrybrains.com/2009/01/02/capturing-autofill-as-a-change-event/

@IgorMinar
Owner

There must be some kind of event that is fired on the node when the autofill/autocompletion happens, we should listen for that event and treat it as input event.

@augustl
@IgorMinar
Owner

@augustl that won't work because we need to be able to trigger model changes by autocomplete. just forcing read from the dom when some other model changes is an incorrect approach as it introduces inconsistency into the system.

@augustl
@Swader

Can't we just forcibly implement the re-check on submit if we're dealing with a form, and ignore the situation when people are using inputs outside forms? There's a lot of such cases going around, it would be just one more "if you're using the form, you're additionally protected against the autocomplete bug because Angular automatically re-syncs the models in case there's autocomplete filled values". If you use input fields without form, pressing enter won't submit either, so it's not normal form behavior and as such, the developer has no right to expect autocomplete to matter anyhow because he has to be handling the input values through JS manually anyway.

When you say it's the browser's fault - the JSON/JSONP bug is the browser's fault too, yet we are still advised to prefix the string ")]}',\n" to every JSON string returned just to be safe.

I believe it would be practical for everyone this way: when using form, if you add an attribute recheck="true", this will make all of the form's children re-check their model values on submit.

It's not a perfect solution, but seeing as a perfect solution is impossible at this time, I think having any solution is better than having none. This way nothing is forced on anyone, and we can all work hack-free.

@shmuel613
@ray-garner

need this

@RWOverdijk

Wouldn't it be even easier if we just set a timeout to re-visit the models? Or will this cause problems to other code (unexpected triggers, race conditions etc.)

@Swader

If there were a way to revisit the models without actually traversing the DOM, that would be an acceptable hack I suppose. Traversing the DOM to find the inputs and re-sync the models wouldn't be acceptable, though.

@jamm

please somebody fix this. I'm ready to pay for this.

@jamm

Very dirty hack: http://stackoverflow.com/a/16800988/680786
but if somebody is forced to solve this issue by any cost - can be useful

@Swader

Bit too dirty for me, grinded the app to a halt when there's several forms with around 6-7 autofillables each. I'll try and make a decent onsubmit hack. It'll need DOM traversal looks like, but this is a serious gap that needs to be patched up with something, even if that something is mud and tar.

@jamm

@Swader 1) absolutely dirty. 2) it works fine with 6 fields, checked (and CPU level check also); 3) "onsubmit" is not enough :( I have form where some inputs should be validated by JS before submit.

@Swader

@jamm I need it on a page where the user can input an arbitrary amount of addresses and thus can summon a theoretically infinite amount of address forms (which are actual directives themselves). With four such forms on screen and 6 autofillables in each, my CPU spiked out. I'm sure it'll be fine for some people though, good stuff either way. Any solution is a good solution at this point, even if it means setting the entire form's autocomplete to off :-|

@jamm

@Swader "infinite" and "setTimeout" should not be together, definitely :)

@tleruitte

We should make the distinction between autofill and autocomplete:

  • Autofill happens at page load in login forms, the browser pre-populates the form with the saved login and password. Autofill also happens in a contact form, when you start typing your name or email, some browsers (e.g. Safari) propose to complete the form based on our personal contact card from the address book.
  • Autocomplete happens when you start typing the same text that has been previously submitted in the same input. Then the browser proposes the previous text that has been submitted. You may or may not use this text.

The autocomplete issue might be easier to fix, since we can trigger a model checking at the blur event. Here is a quick fix:

module.directive('input', [
    function () {
        return {
            restrict: 'E',
            require: '?ngModel',
            link: function ($scope, element, attrs, controller) {
                if (!attrs.type || attrs.type !== "text" || !controller) {
                    return;
                }
                element.on('blur', function () {
                    $scope.$apply(function () {
                        controller.$setViewValue(element.val());
                    });
                });
            }
        };
    }
]);

I don't know if the autofill issue can be easily fixed, since the browser don't seem to trigger any event during autofill (http://avernet.blogspot.in/2010/11/autocomplete-and-javascript-change.html).

@jamm

I'm talking about auto-fill. Thanks for clarification.

@rappo

I've posted a $100 bounty to this issue at Bountysource:
https://www.bountysource.com/issues/67567-form-model-doesn-t-update-on-autocomplete

The bounty will go to the person whose pull request closes this issue.

I'd like to see this issue addressed because it affects Bountysource's signin, bountysource/frontend#78

@matthewgonzalez

My solution is to extend the 'required' directive or whichever validation directive that might be used. I listen for the respective events that each browser throws when autocomplete is made and trigger the 'input' event.

http://jsfiddle.net/matthewgonzalez/fAmHD/10/

@mingue

For us the best choice is to create a new directive at the same level than the form directive with higher priority to be executed before the controller actions and we have subscribed the event submit to refresh the value from the context before to call the actions in the controllers. At this way we always have the last values in our scope before to execute any action.

priority: 10,
link: function ($scope, element, attrs) {
//Extract
    element.on('submit', function (ev) {
      $('input[ng-model]', element).each(function (index, item) {
         if (angular.element(this).attr('type') !== 'checkbox' && angular.element(this).attr('type') !== 'radio') {
         angular.element(this).controller('ngModel').$setViewValue($(this).val());
       }
     });
   });
//Extract
@dmitrybelyakov

@mingue the directive approach is nice!

@tech-no-logical

@mingue thanks, that's the best solution / workaround so far. solved my problems with autofill passwords.

@pjparra

@mingue Thanks for this directive, works really well.

Also, it seems like the bug happens in IE only when the user tries to select an autofill proposition with the mouse. I wasn't able to reproduce the bug when selecting a proposition with the keyboard, which didn't help to clearly identify it.

@jordins

@matthewgonzalez Thanks for your solution! I've renamed the directive so is not replacing the 'required' validation. So far is working great.

@alexpirine

For the username/password autofill issue:

This may be a browser issue as well, I just opened a bug for Chromium:

https://code.google.com/p/chromium/issues/detail?id=307308

Meanwhile, I am using this little workaround:

$(window).load(function() {
  // updates autofilled fields
  window.setTimeout(function() {
    $('input[ng-model]').trigger('input');
  }, 100);
});

It's not very nice, if I use 2 ms instead of 100 ms it doesn't always work, which means that the autofill is performed several ms after the page has been loaded. I don't see any deterministic way to handle this problem.

@gplancke

For me this does the trick on FF 24.0

app.directive("autofill", function () {
    return {
        require: 'ngModel',
        link: function (scope, element, attrs, ngModel) {
            scope.$watch(function () {
              return element.val();
            }, function(nv, ov) {
              if(nv !== ov)
                ngModel.$setViewValue(nv)
            })
        }
    }
});

Should be tested on other browsers, but I see no reason why it should not work...
I see a couple of reasons you shouldn't use it though...

@tech-no-logical

I'm having a problem with the workaround proposed by @mingue above. It seems to work fine in 1.0.8, but fails on 1.2.0. It seems the on('submit') never gets triggered. Does anybody have any idea as to why this is happening ?

edit : this plunk demonstrates the problem. in 1.0.8 the directive gets called first. in 1.2.0 it gets called last.

http://plnkr.co/edit/B1wWKkTdk5QHircmUdu2?p=preview

ideas ?

@noducks

+1

@Yappli

@tech-no-logical : Did you try the code of @gplancke ? It looks perfect.

The workaround proposed by @mingue is limited : Without a submit event it's impossible to access the entry.

@chrisirhc

@gplancke 's watch function may never fire in IE where LastPass doesn't seem to be triggering any event in the browser. I've written a directive that adds a function that runs in intervals, which compares the $viewValue (in ngModel) with the current value of the text field. It doesn't trigger the $setViewValue when the view value is already equal. It's not perfect because it adds timers to the page per field, and takes up more memory. However, it seems to cover all the bases.

app.directive("watchAutofill", [
         '$timeout',
function ($timeout) {
    var INTERVAL_MS = 500;

    return {
        require: 'ngModel',
        link: function (scope, element, attrs, ngModel) {

            var timer;
            function startTimer() {
                timer = $timeout(function () {
                    var value = element.val();
                    if (value && ngModel.$viewValue !== value) {
                        ngModel.$setViewValue(value);
                    }
                    startTimer();
                }, INTERVAL_MS);
            }

            scope.$on('$destroy', function () {
                $timeout.cancel(timer);
            });

            startTimer();
        }
    };
}
]);
@lucassp

@chrisirhc In my app I always have the login form in the DOM but it's not always displayed. So I added two more event listeners to your code to make things easier when the form isn't visible:

scope.$on("loginRequired", startTimer);

scope.$on("loginConfirmed", function () {
  $timeout.cancel(timer);
});
@tbosch tbosch was assigned
@tbosch tbosch referenced this issue from a commit in tbosch/angular.js
@tbosch tbosch fix(input): Support form auto complete on modern browser
Although modern browser support the "input" event, they still only fire
the "change" event when they auto complete form elements
other than the currently selected one.

Related to #1460
d428af7
@tbosch
Owner

Hi,
ok, as far as I understand we have two problems here:

  1. form auto complete by modern browser does not work with angular
  2. form auto complete by browser extensions or bookmarklets does not work.

Regarding 1.): Modern browser support the input event. This event should be fired whenever the input changes. However, when a browser does an autocomplete for other fields than the current one, it only fires the change event. In modern browsers Angular used to only listen to the input event. Now, it's always listening for the change event. Note: On older browser Angular has always listened for the change event...

Regarding 2.): If those third party libraries change the DOM and don't fire any events like change or input Angular has no way of detecting this. In fact, no other js library is able to do this without doing things like polling, which don't scale for a complex single page web app. If you experience this problem, I would suggest filing a bug for that third party library...

Is there anything I missed here? Feedback welcome!

@tbosch tbosch referenced this issue from a commit
@tbosch tbosch fix(input): Support form auto complete on modern browser
Although modern browser support the "input" event, they still only fire
the "change" event when they auto complete form elements
other than the currently selected one.

Related to #1460
a090400
@tbosch
Owner

@all: This just landed in master. Could you double check if we can close this issue now?

@RWOverdijk

@tbosch Could you reference the commit here?

Update Ignore me. I didn't read. :)

@sabbaka

I hope this fix will be in 1.2.3 release.

@marcusnielsen

It seems as firefox for android has this issue for input type="time".
The ng-model scope is not updated when a time is picked.
I've also heard about iPhone 3 with IOS 5 having trouble but that is not yet verified.

I've plunked it on: http://plnkr.co/edit/iO9ClB

The angular-alert should show the time in firefox for android, but shows an empty string instead.

@sabbaka

I've just moved to AngularJS 1.2.3 with tbosch commit, but still saved passwords not works for me on Chrome. I also removed ngDisable from submit button - but anyway it sends empty data.

@tbosch
Owner

@all: The last commit will be in 1.2.3.

@tbosch
Owner

Thanks for testing!
Open issue: Autocomplete for login forms when a page loads. This won't make it into 1.2.3 though...

Details:
In login forms (with username and password), the browser fills out the fields after the page has loaded.
However, the browser does not fire any event for this, and the timing is different between browsers (e.g. on current Chrome it will fire some milliseconds after load event). See e.g. http://stackoverflow.com/questions/11708092/detecting-browser-autofill.

Proposed solution:
Wait 100ms after the DOMContentLoaded event and then check all input fields if:

  1. the model in the scope is empty
  2. element.value is filled but is different than element.getAttribute('value").

In that case, update the scope with the new values. This should only trigger one $digest only if the browser changed something.

@sabbaka

@tbosch Your proposal is same to @alexpirine hack - I'm actually using it right now. But there is another problem - when I first time open my app it works - and I can login with autofilled saved password ( even ngDisabled triggers and enables login button ).
But after I logout - nothing happens, but I'm not sure for now why it's happing.

@mikeobrien

Another issue I've noticed is how FF (At least 25.1 anyways) doesn't fill in the username and password until you start typing the username and select the username you want or tab down into the password field. In this scenario Angular sees the auto completed username but not the auto filled password. Since this happens when the user types it, its not possible to cover this scenario by waiting a few ms after page load.

@tbosch
Owner

@mikeobrien Did you test with the new Angular 1.2.3 release from today? When the browser changes something later it should fire a change event, and we are listening for this now.

@sabbaka What do you mean regarding after logout? What should happen and what is not happening?

@mikeobrien

@tbosch Yeah, 1.2.3. Doesn't appear to be working in that scenario where you tab into the pw field to auto fill it. I couldn't actually get FF to automatically fill out the entire form on page load so I wasn't able to test that scenario. Ended up using @chrisirhc's solution as a stopgap.

@sabbaka

@tbosch Login and password inputs should be autofilled again, but after logout they won't get autofilled. So, for example, if I open an app for the first time chrome autofills login's form and I can login ( after using hack ), but if I logout - fields won't autofill.

@sudhakar

Tested 1.2.3 in firefox 25.0.1. Doesnt seem to work. I have only one user, so the username & password are autofilled. change event never fires..hmm

@martinring martinring referenced this issue in martinring/clide2
Closed

Broken login button #15

@ChinaXing

+1 not works with typeahead.js , I checked the value of input is correct , but the ng-model's value is incorrect !

@tbosch
Owner

Ok, auto complete for fields other than username and password fields should work fine with current browsers.
Here is a demo page that works fine in FF and Chrome: http://plnkr.co/edit/lE17EICzvDAVIdvySnY1?p=preview

However, autocomplete for username/password fields is buggy, at least in Chrome:

We discussed this issue internally and decided that we won't implement polling the DOM for changes that the browsers make when filling in username and passwords without firing a JS event.

Please note that this is a problem that all other JS MVC frameworks also share.

Feel free to implement a polling solution when needed or wait for new browser features like requestAutoComplete in Chrome (http://www.chromium.org/developers/using-requestautocomplete).

@natesalisbury natesalisbury referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@IgorMinar
Owner

so how about this:

let's check if dom mutation observers notify us about the autocompletion event and if they do let's do the following

  • use dom mutation observers (DMO) to get the changes
  • if polyfill for DMO if available
  • not support autocomplete if native or polyfill implementation of DMO is not available

we should ensure that:

  • we handle cases when a jquery plugin updates dom and triggers the change event (don't digest twice)
  • if angular changes the dom, ignore that change too
@tbosch tbosch was assigned
@yoshokatana

here is a hacky little directive I made that addresses both the chrome/safari onload autofill and the firefox/ie onclick/tab variation.

It fires way too many events, but could probably be cleaned up into a workable directive.

@gunta

+1

@fomaa

+1

@marcalj

+1

@Yappli

+1

@tbosch
Owner

@IgorMinar:
Tried mutation observers, but they don't fire when username/password is auto filled by chrome when the page is loaded (see this fiddle http://jsfiddle.net/QN2vL/).

Reason:
Mutation Observers are limited to observing the DOM serialized state, and node.value does not belong to this, see SO answer and chrome issue (marked as won't fix)

@MarcMouallem

Google Maps JavaScript API v3, Place Autocomplete, has this problem as well.

@sagish

+1

@cbier

+4 on behalf of our dev team

@caitp
Collaborator

I'm wondering if we could get a list of browsers which have issues with this, and under what circumstances?

I've just done some investigating during meeting and it seems that Chromium at the very least should emit change on autofill, so that seems like we should be covered there (but please let me know if we're not, it may happen before the input directive is set up, and we might not be initializing the model value from the pre-existing view value, probably for good reason)

I'm not sure how this would affect other browsers, but there's a good chance gecko is working similar to chromium/blink. Test cases so we can figure out exactly what the current issues are would be awesome, it would help a lot to find an effective fix.

@joshkurz
Collaborator

@caitp I can confirm that this is an issue on google chrome v31.0.1650.63, so I don't think chromium is fully covered here.

@caitp
Collaborator

I mean under what circumstances? Is the form created / change event fired before angular bootstrap?

If we're getting the change event before bootstrap, we don't assign the value of the field to the model. We could do this as like a one-time thing, but there are some issues with it:

1) are we overwriting a model value that the developer actually wants us to use
2) did the pre-existing form value come from an autofill, or from somewhere else?

in angular, the model is meant to drive the view, not vice versa, so it's a bit awkward to fit this in. But since people want it, of course it needs to happen somehow, it would just not be good if it results in hurt performance or brokenness

@joshkurz
Collaborator

The input's created/changed event is fired after angular bootstrap, but I don't believe a "change" event is being fired at all.

Since we are trying to set the value in the link function the app has long passed bootstrapping, but no value exists in the element yet. This means the "autocomplete event" or "unicorn event" has not fired yet.

I have come to this conclusion by using this directive.

.directive('autocomplete', function() {
    return {
      require: '^ngModel',
      link: function(scope,element,attrs,ngModelCtrl){
        ngModelCtrl.$setViewValue(element.val());
      }
    }
});

To fix this I am just using jQuery and bypassing the model all together for logins. Kinda frowned on, but Id rather do that than use setTimeout or poll for the value.

@caitp
Collaborator

That's a much better solution than forcing ngModel to do it by default, because we don't know if you want autocomplete/autofill to be affect the model.

Anyways, in Chromium, a change event is fired on autofill --- however there is a subtle distinction between autofill and form autocomplete, which is why it's hard to really picture what's happening. There have also been a lot of inter-browser differences in this area in the past, and I'm not sure how that is looking now, but some browsers will decide not to trigger the 'change' event depending on for instance, field names. And the question of when the events are fired is also a matter which varies from browser to browser.

So it's really a hard problem to solve effectively, and providing a custom directive to tell ngModel to update the model value on load is probably the best thing you can do for it. However there would still be cases where UI changes wouldn't affect the model value unfortunately :( welcome to the web platform, where big is small, round is square, red is green, fish fly and birds swim. It' s very hard to come up with a sensible solution for all browsers :(

@jon077

+1

@ecaron

+1

@marcopg marcopg referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@marcopg marcopg referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@chesleybrown

I too would really like to see this fixed and just magically working in angular. Since that hasn't happened yet, I decided to create a simple directive to solve the situation I needed.

It's available here for anyone interested: https://github.com/chesleybrown/autofill-directive

Basically I just needed the model to be updated once the user submitted the form (I didn't need the model to be updated instantly upon the browser autofill on page load). This worked perfectly for what I see as the most common case: the login form. Once the user submits the login form, the model is updated with what the browser autofilled in and the user is logged in.

Hopefully some of you find it useful too. :)

@marcopg marcopg referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@marcopg marcopg referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@guanbo

@chesleybrown is worked on 1.2.7

@soudmaijer

I am using 1.2.7 but the issue still exists.

I am using autocomplete="off" now on a form, which is a crap solution, but at least it is clear for the user that autocomplete doesnt work.

@cbier

@soudmaijer I think that @guanbo is talking about the directive that @chesleybrown made

@ecaron

The directive from @chesleybrown helped me fix the issue for Chrome (against 1.2.7), but Firefox users w/ autofill are still feeling the burn.

Revoking previous comment. @chesleybrown implementation still works in FF, I was using it wrong.

@chesleybrown

Are you sure @ecaron? It's working in Firefox for me. That's how I originally coded it (I haven't even tested it in Chrome yet, but thanks for letting me know it works there :smile_cat: ). Maybe a caching problem?

@speg speg referenced this issue from a commit in speg/habitrpg
@speg speg manual username & password input
fixes #2295
when using browser/plugin auto-complete from what I understand certain browser events
are not emmited and thus angular never picks up the new values.

This patch adds a fallback using jQuery to set the username & password if the angular
properties are not set.

see: angular/angular.js#1460
99dccc2
@speg speg referenced this issue in HabitRPG/habitrpg
Merged

manual username & password input #2335

@Yappli

Thanks @speg but your PR depends on jQuery, so it's will be impossible to merge-it to angular.js

@speg

@Yappli sorry, I was just referencing this issue in a PR to another repo. Didn't intend it to be a PR to angular.js

@tbosch
Owner

Short update: We are working on a polyfill that triggers the change event at the right time so everything is find, also for login forms.

This will be a separate javascript file that needs to be loaded and which patches jQuery / jQLite.

Almost done, only the test cases can't be automated (will be semi-automated with manual steps in between).

@marcalj

@tbosch Awesome!! Thanks!!!! :D

@evictor

I wrote a solution to this here that is semantically sound AngularJS: http://victorblog.com/2014/01/12/fixing-autocomplete-autofill-on-angularjs-form-submit/

@jamm

@evictor on-submit directives are useless (too simple to implement without directive). Main problem is triggering events on change, to check user's input before submit.

@blaise-io

@tbosch The 1.2.9 milestone is closed. Does that means this will probably be in 1.2.10?

@friksa

+1

@mems

For who want to fix that annoying thing, I've made a decoration of inputDirective, based on #1460 (comment):

// Due to browsers issue, it's impossible to detect without a timeout any changes of autofilled inputs
// https://github.com/angular/angular.js/issues/1460
// https://github.com/angular/angular.js/issues/1460#issuecomment-28662156
// Could break future Angular releases (if use `compile()` instead of `link())
// TODO support select
angular.module("app").config(["$provide", function($provide) {
    var inputDecoration = ["$delegate", "inputsWatcher", function($delegate, inputsWatcher) {
        var directive = $delegate[0];
        var link = directive.link;

        function linkDecoration(scope, element, attrs, ngModel){
            var handler;
            // By default model.$viewValue is equals to undefined
            if(attrs.type == "checkbox"){
                inputsWatcher.registerInput(handler = function(){
                    var value = element[0].checked;
                    // By default element is not checked
                    if (value && ngModel.$viewValue !== value) {
                        ngModel.$setViewValue(value);
                    }
                });
            }else if(attrs.type == "radio"){
                inputsWatcher.registerInput(handler = function(){
                    var value = attrs.value;
                    // By default element is not checked
                    if (element[0].checked && ngModel.$viewValue !== value) {
                        ngModel.$setViewValue(value);
                    }
                });
            }else{
                inputsWatcher.registerInput(handler = function(){
                    var value = element.val();
                    // By default value is an empty string
                    if ((ngModel.$viewValue !== undefined || value !== "") && ngModel.$viewValue !== value) {
                        ngModel.$setViewValue(value);
                    }
                });
            }

            scope.$on("$destroy", function(){
                inputsWatcher.unregisterInput(handler);
            });

            // Exec original `link()`
            link.apply(this, [].slice.call(arguments, 0));
        }

        // Decorate `link()` don't work for `inputDirective` (why?)
        /*
         directive.link = linkDecoration;
         */
        // So use `compile()` instead
        directive.compile = function compile(element, attrs, transclude){
            return linkDecoration;
        };
        delete directive.link;

        return $delegate;
    }];

    $provide.decorator("inputDirective", inputDecoration);
    $provide.decorator("textareaDirective", inputDecoration);
    //TODO decorate selectDirective (see binding "change" for `Single()` and `Multiple()`)
}]).factory("inputsWatcher", ["$interval", "$rootScope", function($interval, $rootScope){
    var INTERVAL_MS = 500;
    var promise;
    var handlers = [];

    function execHandlers(){
        for(var i = 0, l = handlers.length; i < l; i++){
            handlers[i]();
        }
    }

    return {
        registerInput: function registerInput(handler){
            if(handlers.push(handler) == 1){
                promise = $interval(execHandlers, INTERVAL_MS);
            }
        },
        unregisterInput: function unregisterInput(handler){
            handlers.splice(handlers.indexOf(handler), 1);
            if(handlers.length == 0){
                $interval.cancel(promise);
            }
        }
    }
}]);

Update code: add inputsWatcher + fix support checkoxes and radios buttons

@tbosch
Owner

@blaise-io I am on parental leave right now for 1 1/2 more weeks. So it won't be before then...

@cbier

@tbosch Kudos for putting your family first, it's good to see, and double thanks for working on a fix :)

@jamesdaily jamesdaily referenced this issue from a commit in jamesdaily/angular.js
@tbosch tbosch fix(input): Support form auto complete on modern browser
Although modern browser support the "input" event, they still only fire
the "change" event when they auto complete form elements
other than the currently selected one.

Related to #1460
1c24237
@jamesdaily jamesdaily referenced this issue from a commit in jamesdaily/angular.js
@tbosch tbosch fix(input): Support form auto complete on modern browser
Although modern browser support the "input" event, they still only fire
the "change" event when they auto complete form elements
other than the currently selected one.

Related to #1460
767d9c0
@tbosch
Owner

Hello all,
here is the initial polyfill that triggers a change event when the browser changes form fields without triggering a change event: https://github.com/tbosch/autofill-event

The polyfill will check for changes on document load and also when an input is left (only in the same form). However, you can trigger the check manually if you want to.

The project has unit tests as well as semi automatic tests, so we finally have a place to collect all the different use case together with the required browser settings.

Please note: This polyfill works with plain AngularJS apps, with AngularJS/jQuery apps but also with plain jQuery apps that do not use Angular.

Feedback welcome, but please as issues (or better PRs) on that new project!

@tbosch tbosch modified the milestone: 1.2.12, 1.2.11
@tbosch
Owner

Ok,
I am closing this now. Please file any missing use case or bugs related to auto fill events in the new project https://github.com/tbosch/autofill-event

Thanks all!

@tbosch tbosch closed this
@jamm

@tbosch so it will not be build in Angular code, we should always include this file?

@tbosch
Owner

@jamm Yes, for now, we won't build this into Angular code. This is a bugfix for the browser, and also works without Angular (e.g. for plain jQuery apps).

@Chenzo

@tbosch Thanks for your polyfill! You just totally ended my headaches.

@lgfausak

This is working great if the form that I am using autofill with is the form that is displayed when I load the page. However, if I use ui.router to navigate to the form that is being autofilled, it doesn't work. I hope that makes sense!

I see the comment about the manual application:

$el.checkAndTriggerAutoFillEvent(): Execute the check for all DOM elements in the given jQuery / jQLite element.

I am not a javascript programmer, I work more on the backends. I have tried just about everything to try this command and can't get it to work. I assume that the $el is a variable that I need to substitute from my code? I am including jQuery, then angular. How do I call this manually?

-g

@marcalj

@lgfausak Try this: $('input').checkAndTriggerAutoFillEvent();

@lgfausak

Thanks, that did the trick!
Just to follow up for those that are as slow as me with regard to ng.

First, I had to put these in the top of my index.html file

Just doing that fixed the issue when a autofill page was directly loaded. But, if I navigated to an autofill page I still had an issue...

Here is my input form with name and password:


Username: <input type="text" name="identification" ng-model="credentials.identification" required/>
Password: <input type="password" name="password" ng-model="credentials.password" required/>
<button type="submit">Login
</form>

Then in the .js file which has my input form's submit handler:
$scope.login = function() {
$('input').checkAndTriggerAutoFillEvent();
... then I just continue, the autofill worked in all cases at this point...

-g

Thanks to all of you guys! (My son helped me with the javascript. It turns out that all I needed to do was include jQuery. Being a backend programmer this wasn't obvious to me :-) ).

@marcalj

"My son helped me with the javascript", this phrase should be in a fact's wall!!! :D

@lgfausak
@tbosch
Owner

@lgfausak This should work out of the box, even with ui router. Could you create a sample app as plunker/jsfiddle to show the problem and create an issue in the new repo?

@ProdigyView

Does anyone else get this error?

Cannot read property '$viewValue' of undefined

@tbosch
Owner

@ProdigyView Could you create an issue on the new repo and also create a punker/jsfiddle to reproduce it?

@nebulade nebulade referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@marvinferreira

I pass user name and password direct to my Service using jQuery, it's a worth workaround! =]

@a-peyrard a-peyrard referenced this issue from a commit in a-peyrard/restx
@a-peyrard a-peyrard - Correct the bug with browser autofill (This bug is due to a known b…
…ug of angularjs angular/angular.js#1460, but as the correction is a little bit too much code to add, I prefer a less verbose solution found there: http://victorblog.com/2014/01/12/fixing-autocomplete-autofill-on-angularjs-form-submit/).

- Default focus on the username input (using the html5 attribute autofocus).
- Change login button type to "submit" in order to be able to validate the form with the enter key.
7d7b076
@bosskovic bosskovic referenced this issue in angular-ui/bootstrap
Closed

typeahed does not update scope on select #2000

@stsvilik stsvilik referenced this issue from a commit
@tbosch tbosch fix(input): Support form auto complete on modern browser
Although modern browser support the "input" event, they still only fire
the "change" event when they auto complete form elements
other than the currently selected one.

Related to #1460
47b3600
@Qwlouse Qwlouse referenced this issue in Qwlouse/Findeco
Closed

MultiValueDictKeyError at /.json_login/ #304

@kumarharsh

@evictor thanks! your solution works.

@haferje

for anyone else looking here, http://stackoverflow.com/a/19854565/1225924 worked for me, and is a much simpler solution than backporting the fix if you are not on the latest release.

@huei90

Cool for fix it.

elem.find('input, textarea, select').trigger('input').trigger('change').trigger('keydown');
scope.$apply(attrs.ngSubmit);

works

what's the different between

$timeout(function () {
    elem.find('input, textarea, select').trigger('input').trigger('change').trigger('keydown');
});
@kumarharsh

The execution of a function inside $timeout is synced with the angular digest cycle, so you don't have to call the $apply manually.
IMO The $timeout method is the 'correct' one.

@edzius

In case autofill sync required on submit only, updated huel90 approach:

.directive('autofillSubmit', function () {
  'use strict';

  return {
    restrict: 'A',
    priority: -10,
    link: function (scope, element) {

      element.on('submit', function () {
        element.find('input, textarea, select').trigger('input').trigger('change').trigger('keydown');
      });

    }
  };
});

By using directive on <form> along with ng-submit, priority < 0 makes directive to be linked first so model get updated before ng-submit expression executed.

@lgalfaso
Collaborator

@evictor @edzius Can you please explain here how your solution compares to #1460 (comment) ?

@caitp
Collaborator

Since browsers are supposed to dispatch "autocomplete" and "autocompleteerror" events now (and some do), it is probably a sensible idea for angular to handle them.

However, the HTML5 spec says autofilled content to not be validated, so we shouldn't run the validation pipeline when autocompleted, I think.

@matsko can we add something like that into the validation pipeline change?

@evictor

@lgalfaso it does exactly the same thing in a slightly different way. Instead of using priority to precede ngSubmit (which I admit is probably a cleaner way of doing this), it unbinds submit, then reattaches a new submit handle that A) triggers the appropriate events and B) $apply()s the nbSubmit expression.

@gmoulin

A "fix" for this bug using a modified version of the directive approach, since jqLite does not provide trigger function.
Works fine for a login form.

    .directive('autofillSubmit', [function(){
        return {
            restrict: 'A',
            priority: -10,
            link: function( scope, element ){
                element.on('submit', function(){
                    _.forEach(element[0].querySelectorAll('input'), function( field ){
                        field.focus();
                        field.blur();
                    });
                });
            }
        };
    }])
@stefanotorresi

starting off @evictor solution, I made a form directive decorator for a seamless integration and no jQuery usage, here is the gist: https://gist.github.com/stefanotorresi/1de83e989fd780873af6
will add some tests later.

@akofman

@stefanotorresi Thx for your solution.
Just a small detail, it seems JQlite find method is based on getElementsByTagName which can't select multiple tags as you suggested it in your gist (line 42).

@stefanotorresi

@akofman thanks! the gist is now updated accordingly

@Pistos Pistos referenced this issue in Pistos/angular-sinatra-authentication-example
Open

Login form doesn't work with Chrome form pre-fill #1

@scmx scmx referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@swlasse

I used the solution by @evictor - works out of the box - thanks.

@ryanmc2033

Can someone explain why angular can't just double check the actual form fields on ng-submit? This seems really easy and should have been implemented a long time ago.

@evictor

@ryanmc2033 I agree 100%. Will someone please implement and submit PR? :)

@caitp
Collaborator

@ryanmc2033 if you think it's easy, send a pull request =) Tbosch put together https://github.com/tbosch/autofill-event a while ago as a way to solve this, so you should be able to use that.

I thought it was linked in this issue, but I don't see it.

@jamm

@ryanmc2033 it's not enough. Some apps want check values on filling, not on submit.

@ryanmc2033

@jamm yes, but validation only becomes a problem when an autofilled form is submitted. Besides, @caitp said earlier "the HTML5 spec says autofilled content to not be validated,". So we should be skipping validation anyways.

@xzer

It seems that it has not been resolved yet.

There is a msdn link which explains we should use onpropertychange instead of onchange to capture autofill event.

http://msdn.microsoft.com/en-us/library/ms533032%28VS.85%29.aspx

http://msdn.microsoft.com/en-us/library/ms536956(v=vs.85).aspx

Is this helpful?

@xzer

I add the following row experimentally and it worked on IE 8!

if ($sniffer.hasEvent('propertychange')) {
element.on('propertychange', deferListener);
}

@caitp
Collaborator

@xzer the "propertychange" event is an IE thing, so this wouldn't benefit most users, or most of the supported browsers, and is very different from detecting "autofill"

@xzer

yes, it is a IE thing, so we need support it at least for IE8, I test it on IE8 and IE11, sorry I have only this two version in my machine, and it shows that IE11 don't have this event, which means "propertychange" is a IE 8 (or other old version) only event, which also means at least we can make IE 8 work correctly.

@caitp
Collaborator

and is very different from detecting "autofill"

It's more like a primitive version of Object.observe, and you'd run into bugs whenever any property other than value on the input changed (I'd also be surprised if changing the value from script context didn't queue up dispatch of another propertychange event, unless it's even hackier than I thought). Plus, this change would still only apply to input elements, not select elements (for example). And even for input elements, it would not even remotely benefit the vast majority of users.

@tbosch's library is a better solution for this, imo.

@xzer

you'd run into bugs whenever any property other than value on the input changed
this change would still only apply to input elements, not select elements (for example)

for this event, we can add a wrapper function to fire the original deferListener for input element and value property only.

it would not even remotely benefit the vast majority of users.

since this event is IE 8 only, which means at least IE8 users would benefit from this event and without any side effect for others, imo

and is very different from detecting "autofill"

at the msdn page I pasted, there is a statement which declared that "onpropertychange" is the official way to detect autofill: To determine when a user updates the content of a field from the AutoComplete dialog box, use the onpropertychange event, rather than the onchange event, because the onchange event does not fire. so I don't think using this event is evil.

@kumarharsh

@xzer Angularjs is a general-purpose library used by the whole world. Whole world meaning X browsers and their Y versions. Adding code which is known to only be for IE8 is not a very good idea in this regard, is it? Anyways, Angular 1.3 dropped support for IE8 (rightly so), and thus as far as I know, no steps would be taken in this regard from the Angular team.

As a workaround, you can monkeypatch your own angularjs library to include support for IE8 if you wish to do so.

@xzer

@kumarharsh I agree with your opinion that angular js is designed for all browsers and all versions. I also think this bug fix is not necessary for the newest angular js version. But as a matter of fact, the current stable version shown on the office site is 1.2.x which declares supporting IE 7 & 8. For the old ages, IE only codes, Firefox only codes, Chrome only codes, we were suffering from all of those magic things, I understand it, and the current situation is that there are many developer who are still suffering from those things because the damned XP and old IE which are still used by many big companies, I believe the terrible situation would still continue for about 1-2 years.

In conclusion, I believe it is worth fixing this problem in before 1.2.x versions officially, not my own monkeypatch.

@andrew-luhring

@kumarharsh I actually disagree with your sentiment- nobody likes having to support IE ,
but
that doesn't mean that we should make the users of our websites suffer by choosing to not implement a bug fix. When Internet Explorer was the master, we had to support Chrome, Safari and Firefox users; now that Chrome has all but annihilated every other modern browser in the landscape
( except for Firefox :-P )
we still need to support IE8 until XP dies.
You don't win users by forcing them to do something (see: Microsoft),
you win them by showing them a better way (see: Google / Apple). Chromeframe is a HUGE reason why Chrome has taken over.

TLDR:

it's a bug fix that supports a browser that a few million people still use so a lot of us still have to deal with. If it helps some people, hurts no one, and the solution is in your hands- which is what @xzer appears to be asserting - then why stand in the way?

@naktinis

There are a few bug reports filed for Firefox. I've filed one back in 2008 - https://bugzilla.mozilla.org/show_bug.cgi?id=430931, and there's one recent specific to this thread https://bugzilla.mozilla.org/show_bug.cgi?id=950510. Feel free to click "vote" and comment.

@deckar01 deckar01 referenced this issue in stellar/stellar-client
Merged

Allow angular to listen to autofill events #365

@rutwick

+1 for the issue. The auto-completed fields have blank values in the models. I tried using some of the directives posted by other users here. But they never work.
Here is a simple fix that I used to get around this problem. In your controller, check if the details exist in the model, if not use the raw form field values.
Example, if your model is car, and the field is car.name, check if the value is empty in the controller, and use the raw text input value [$(...).val()] if yes. Then set the value for $scope.car in your controller.

(Pardon my terminology, I'm new to Angular)

@afrimberger afrimberger referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@wldaunfr wldaunfr referenced this issue from a commit
Commit has since been removed from the repository and is no longer available.
@swaron

my workaround

var myAutofillDirective = [ function() {
    return {
        require: 'ngModel',
        link:function(scope, element, attr, ngModel) {
            var origVal = element.val();
            if(origVal){
                ngModel.$modelValue = ngModel.$modelValue || origVal;
            }
        }
    };
} ];    
@davisford

I had to modify @evictor's solution a tad, since I am not using jQuery, and thus don't have .trigger. Also, I only have <input> in my form, and the find('input, select, textarea') did not return anything for me, so I only search for input.

angular.directive('autofillFix', function () {

    return {
      link: function(scope, elem, attrs) {
        // Fixes Chrome bug: https://groups.google.com/forum/#!topic/angular/6NlucSskQjY
        elem.prop('method', 'POST');

        // Fix autofill issues where Angular doesn't know about autofilled inputs
        if(attrs.ngSubmit) {
          setTimeout(function() {
            elem.unbind('submit').bind('submit', function (e) {
              e.preventDefault();
              var arr = elem.find('input');
              if (arr.length > 0) {
                arr.triggerHandler('input').triggerHandler('change').triggerHandler('keydown');
                scope.$apply(attrs.ngSubmit);
              }
            });
          }, 0);
        }
      }
    };
  });
@binarykitchen

Grrrr, none of the above suggestions worked for me. AngularJS really should not make it more complicated for us. AngularJS shouldn't obstruct the autocompleter of a browser.

@jamm

@binarykitchen my dirty hack (#1460 (comment)) still works fine :)
And it's not AngularJS' problem - browsers just don't send events about autocompletion, so blame browsers. Or fork-fix them and send PR )

@dlitz

"Browsers just don't send events about autocompletion".
Exactly, so it's ridiculous for AngularJS to assume that they do.

@andrew-luhring

AngularJS is a product of Googe so it does make at least a little bit of sense that they do.

@binarykitchen

So it's a browser issue then? Is there a ticket for that on the Google Chrome issue tracker?

@PowerKiKi

@binarykitchen may I suggest you at least try to search before writing message that are emailed to 108 people. In this very thread the ticket were already mentioned (CTRL+F magic):

Chrome: https://code.google.com/p/chromium/issues/detail?id=135307
Firefox: https://bugzilla.mozilla.org/show_bug.cgi?id=430931 https://bugzilla.mozilla.org/show_bug.cgi?id=950510

Also @tbosch may I suggest you lock this thread ? I feel that everything that could be said was already said, with numerous workarounds mentioned. Most notably https://github.com/tbosch/autofill-event which is something that should work for every cases. The discussion is no longer constructive IMHO.

@tbosch
Owner

I agree with @PowerKiKi, locking this thread now.

@tbosch tbosch locked and limited conversation to collaborators
@manuroe manuroe referenced this issue from a commit in matrix-org/synapse
@manuroe manuroe Use autofill-event.js to workaround browsers issue: Form model doesn'…
…t update on autocomplete

angular/angular.js#1460
aa347b5
@jesselpalmer jesselpalmer referenced this issue from a commit
@tbosch tbosch fix(input): Support form auto complete on modern browser
Although modern browser support the "input" event, they still only fire
the "change" event when they auto complete form elements
other than the currently selected one.

Related to #1460
ad0f5d9
@IgorMinar
Owner

Just an update that the issue is fixed in Chrome M40. Maybe even M39.

There are still issues with Safari 7 and 8. In FF34 the forms autofill works well, but password autofill is still broken.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Something went wrong with that request. Please try again.