How to not allow user to enable input editing [duplicate] - html

I have a button as follows:
<input type="submit" class="button" value="FooBar" name="FooBar" id="FooBar" disabled="disabled">
I am enabling this button only when certain parameters are met. To test whether it was secure, I pressed F12 (or right click -> Inspect Element) and edited out the text disabled="disabled". Doing this overrides my code and that is scary. How can I prevent someone from changing it in this manner?
I am using php and jquery in this page and using the latter to enable or disable the button. I have checked the jquery click function and it not only executes, but shows the button as not disabled. The alert below reads Disabled: false
$("#FooBar").click(function(){
alert('Disabled: ' + $(this).is('[disabled=disabled]'));
})
So how can I prevent a user from changing the button disabled state and thus overriding my logic?

You can disable the right-click by doing:
document.addEventListener('contextmenu', event => event.preventDefault());
but it is not recommended. Why? It achieves nothing other than the annoying user
OR
Alternatively, a better approach is to recheck your validations in submit action and simply returns if it fails, in this case, if user inspects and changed the state of a button, the button stays idle and will not allow to proceed
$("#FooBar").click(function() {
if (!this.acceptenceCriteria()) {
return;
}
alert('Disabled: ' + $(this).is('[disabled=disabled]'));
})

You can't stop people from using dev tools.
You can try a couple of tricks to disable right clicking (like the one below) which will stop some number of people but ultimately the solution to your problem is to use html and http properly.
$(document).bind("contextmenu",function(e) {
e.preventDefault();
});

Related

Cypress or Puppeteer: How to test page with a react select popup/popover?

Request:
Either with Cypress (preferably) or using extending Cypress with Puppeteer via cy.task(), being able to perform a test on a system-generated popup menu?
This popup menu element cannot be inspected by Chrome Devtools and is thereby not navigatable by either CSS selectors or XPath.
Details: I am using Cypress for UX testing and extend in limited cases with custom cy.task() with Puppeteer.
The web page under test has a dropdown selection that generates a popup menu, source is this npm module:
npm react-select-async-paginate
Under inspections, the popup menu is generated from an and it has these two attributes:
aria-haspopup="true"
role="combobox"
Appreciate assistance, thank you
22 Feb, Updated
This is the generated react-select-async-paginate:
<div>
<div class="***-singleValue">Offer Letter w/ Signature</div>
<div class=" css-ackcql" data-value="">
<input
id="react-select-2-input"
aria-autocomplete="list"
aria-expanded="false"
aria-haspopup="true"
aria-controls="react-select-2-listbox"
aria-owns="react-select-2-listbox"
role="combobox">
</div>
</div>
This is the attempt for selecting an option, but it does not loads selected option into <div class="***-singleValue">.
This Cypress script selects an option:
cy.get(`${selectorReactSelectPaginate}`)
.find('input[role="combobox"]')
.focus()
.type($valueSelect, { force: true })
.then(() => {
cy.wrap(true);
});
As would able to validated using this Cypress script:
cy.get(selectorReactSelectPaginate)
.find('div[class*="-singleValue"]')
.contains($valueSelectContains)
.then(() => {
cy.wrap(true);
});
Yes, the option list is tricky to get at in devtools because of the blur event (which comes from the library itself). One approach is open devtools and watch carefully as you click open the select.
Using react-select-async-paginate - Simple Example, when I click open the select I can see this div appearing and disappearing
<div id="react-select-2-listbox">
So I can use Cypress to get a look inside that
cy.get('[role="combobox"]').click()
cy.get('#react-select-2-listbox')
.then($listbox => {
console.log($listbox)
})
Now in devtools console, check out children property (has one child), then the child's children - these look like the options to be tested.
The common selector is an id starting with react-select-2-option, so I can test like so
cy.get('[role="combobox"]').click()
cy.get('#react-select-2-listbox')
.find('[id^="react-select-2-option"]') // all div's with id starting react-select-2-option
.should('have.length', 10)
.eq(3) // check out the 4th option
.invoke('text')
.should('eq', 'Option 4') // passes
Selecting an option by typing into the box
Two things affect this method of selecting
the dropdown list changes (reloads) as you type characters
the element 'div[class*="-singleValue"]' only appears after you confirm the typed value (either enter key or blur(), I'm not sure which).
This worked for me
// Type in the option
cy.get(selectorReactSelectPaginate)
.find('[role="combobox"]')
.type(valueToSelect)
// Wait for the listbox to respond
cy.get('#react-select-2-listbox')
.should('contain', valueToSelect)
// Blur or enter will set the value
cy.get(selectorReactSelectPaginate)
.find('[role="combobox"]')
.type('{enter}')
.blur()
// Check the value
cy.get(selectorReactSelectPaginate)
.find('div[class*="-singleValue"]')
.should('contain', valueToSelect)
A neat trick with test runner is to add a .wait() after the dropdown selection appears. A snapshot of the DOM will be created and you can click on the .wait() to view the snapshot and use dev tools to inspect the dropdown selection.

How to fix Angular bug requiring user to click a separate element before choosing a second mat chip

Here is the link for an example of the issue I will attempt to describe. In the chips autocomplete example, click the text box to select a new fruit.
Now, before clicking anywhere else, click again on the text box as you did before.
This should result in no options showing up. The issue here is that the user must either begin keying in a new selection or first click another element in the window before matchip will show the options to choose from. I am wondering if there is a way to fix this issue. I would like a user to be able to choose a selection from the list and then immediately click the text box as they had before and make a new selection.
I'm using mat-chip-list inside an outer *ngFor iterating over a FormArray.
Here is what I'have done. It's pretty efficient :
<input
#validatorInput
#operationTrigger="matAutocompleteTrigger"
[formControl]="contactCtrl"
[matAutocomplete]="auto"
[matChipInputFor]="chipList"
(blur)="contactCtrl.setValue(''); validatorInput.value='';"
(click)="contactCtrl.setValue(''); validatorInput.value=''; operationTrigger.openPanel()">
The trick is
Always clear your html input and your (shared) formControl with an empty and not null value each time the blur and click events occur.
Do NOT do this 'clear' on the input focus event. (Because when you delete the last chip, the input is auto-focus and you will have the famous Expression has changed after it was checked.
Call operationTrigger.openPanel(); when the user click on the input
Setting contactCtrl.setValue(''); allows your autocomplete panel to be automatically opened when you call operationTrigger.openPanel()
Setting validatorInput.value=''; is just a way to properly sync your formControl with the html input to ensure a good UX/UI behavior.
Inside my formArray, the formControl is the same for all the inputs but it does not matter since the user can only manipulate one input at a given time
Since you didn't post your code and you mention the example on the material site I'm going to do it as a fork of the stackblitz example they have on their site.
But this will allow you to open the autocomplete panel again despite having had the cursor there and choosing an option previously.
// Using MatAutocompleteTrigger will give you access to the API that will allow you to
// to open the panel or keep it open
...
#ViewChild(MatAutocompleteTrigger, {static: false}) trigger: MatAutocompleteTrigger;
...
ngAfterViewInit() {
fromEvent(this.fruitInput.nativeElement, 'click')
.pipe(
tap(() => {
this.trigger.openPanel()
})
).subscribe()
}
Link to the full stackblitz:
https://stackblitz.com/edit/angular-sb38ig

cannot get value when I click the auto select [duplicate]

When you have saved username and password for some site Chrome will autofill that username and password, but if you try to get the value for the password input field it is empty String even though there is value there ******.
If you click somewhere on the page no mater where the value of the input type="password" will be filled.
This is Fiddle user/pass of the structure of the html and the console.log command. It cannot be seen here but it can be reproduced on every page that has login form and the username and password are autofilled on the load of the page. If you inspect the value of the field before clicking anywhere else on the site it will be empty String.
This is not the case in Firefox or Internet Explorer it will fill the value of the input element with the password.
I am using Windows 7 Ultimate 64-bit OS and Google Chrome version is 48.0.2564.97 m
Is this normal behavior, bug or?
UPDATE:
If you click on F5 to reload the page and inspect the password field the value for password will be there. If you click the reload button in Chrome in top left corner the value for the password field will be empty string.
This seems to be a bug in Chrome. When Chrome auto-fills a password on an initial page load (but not a refresh), the value appears in the form field on-screen, but querying passwordField.value in Javascript returns an empty string. If you depend on seeing that value in Javascript, this prevents you from doing so. Once the user does any other action on the page, such as clicking anywhere on the page, the value suddenly becomes visible to Javascript.
I'm not actually 100% sure if this is a bug, or if there is a security reason for doing this such as preventing a hidden frame from stealing your password by tricking the browser into filling it in.
A workaround that we have used is to detect the background color change that Chrome makes to fields that it has auto-filled. Chrome colors the background of auto-filled fields yellow, and this change is always visible to Javascript even when the value is not. Detecting this in Javascript lets us know that the field was auto-filled with a value, even though we see the value as blank in Javascript. In our case, we have a login form where the submit button is not enabled until you fill in something in the password field, and detecting either a value or the auto-fill background-color is good enough to determine that something is in the field. We can then enable the submit button, and clicking the button (or pressing enter) instantly makes the password field value visible to Javascript because interacting with the page fixes the problem, so we can proceed normally from there.
Working Answer as of July 8, 2016
Adam correctly stated this is a bug (or intended behavior). However, none of the previous answers actually say how to fix this, so here is a method to force Chrome to treat the autocompleted value as a real value.
Several things need to happen in order, and this needs to only run in Chrome and not Firefox, hence the if.
First we focus on the element. We then create a new TextEvent, and run initTextEvent, which adds in a custom string that we specify (I used "#####") to the beginning of the value. This triggers Chrome to actually start acting like the value is real. We can then remove the custom string that we added, and then we unfocus.
Code:
input.focus();
var event = document.createEvent('TextEvent');
if ( event.initTextEvent ) {
event.initTextEvent('textInput', true, true, window, '#####');
input.dispatchEvent(event);
input.value = input.value.replace('#####','');
}
input.blur();
Edit August 10, 2016
This only works right now in Chrome on Windows and Android. Doesn't work on OSX. Additionally, it will stop working at all in Sept 2016, according to:
https://www.chromestatus.com/features/5718803933560832
Also, I've opened a Chromium ticket.
https://bugs.chromium.org/p/chromium/issues/detail?id=636425
As of August 12, a member of the Chrome team said on the above ticket that the behavior won't be changing because they don't consider it a bug.
Long-term Work-Around Suggestion:
That said, the current behavior has been tweaked from when it was first implemented. The user no longer has to interact with the password input for the value to be reported. The user now just needs to interact (send a mouse or keyboard event) with any part of the page. That means that while running validation on pageload still won't work, clicking on a submit button WILL cause Chrome to correctly report the password value. The work-around then, is to revalidate all inputs that might be autocompleted, if that is what you are trying to do, on submit.
Edit December 13, 2016:
A new Chromium ticket has been opened and is being received better. If interested in changing this behavior of Chrome's, please star this new ticket:
https://bugs.chromium.org/p/chromium/issues/detail?id=669724
Continuing from what Kelderic said, here's my work around. Like a lot of people, I don't need the actual password value. I really just need to know that the password box has been autofilled, so that I can display the proper validation messages.
Personally, I would not use suggested solution to detect the background color change cause by Chrome's autofill. That approach seems brittle. It depends on that yellow color never changing. But that could be changed by an extension and be different in another Blink based browser (ie. Opera). Plus, there's no promise Google wont use a different color in the future. My method works regardless of style.
First, in CSS I set the content of the INPUT when the -webkit-autofil pseudo-class is applied to it:
input:-webkit-autofill {
content: "\feff"
}
Then, I created a routine to check for the content to be set:
const autofillContent = `"${String.fromCharCode(0xFEFF)}"`;
function checkAutofill(input) {
if (!input.value) {
const style = window.getComputedStyle(input);
if (style.content !== autofillContent)
return false;
}
//the autofill was detected
input.classList.add('valid'); //replace this. do want you want to the input
return true;
}
Lastly, I polled the input to allow the autofill time to complete:
const input = document.querySelector("input[type=password]");
if (!checkAutofill(input)) {
let interval = 0;
const intervalId = setInterval(() => {
if (checkAutofill(input) || interval++ >= 20)
clearInterval(intervalId);
}, 100);
}
It is amazing that in 2021 this has not been solved in Chrome yet, I have had issue with autocomplete since 2014 and still nothing.
Chrome functionality autocomplete is misleading for the user, I do not know what are they trying to achieve but does not look good.
As it is now, form appears showing auto-completed text (user/email/pass) to the user, but in the background html - values are not inside of the elements.
As values are not in fields custom validation will disable submit button.
Script that checks fields values will say value is null, which is even more confusing for the user as s/he can see text is there, and can assume it is valid, leading to confusing delete-one insert one character. (Embarrassingly, I have to admit I did not know that you need to click in the body of the HTML, so I wonder how many users don not know the same)
In my case I wanted to have empty field always and then fount out it is just needlessly spent time to make it work.
If we try autocomplete=off we will discover that it is not working. And to validate fields and let say enable button we need to do some trickery.
(Have in mind that I have tried autocomplete=password new-password) and other type of Hocus-Pocus trickery from official resource.
At the end I have done this.
<script>
$('#user').value = ' '; //one space
$('#pass').value = ' '; // one space - if this is empty/null it will autopopulate regardless of on load event
window.addEventListener('load', () => {
$('#user').value = ''; // empty string
$('#pass').value = ''; // empty string
});
</script>
So, it will blink for a split second in some cases in password field with * not ideal but :/ ...
Here's my solution to this issue:
$(document).ready(function(){
if ( $("input:-webkit-autofill").length ){
$(".error").text("Chrome autofill detected. Please click anywhere.");
}
});
$(document).click(function(){
$(".error").text("");
});
Basically, clicking makes the input visible to the user, so I ask the user to click and when they do, I hide the message.
Not the most elegant solution but probably the quickest.
$(document).ready
does not wait for autofill of browser, it should be replaced by
$(window).on("load", checkforAutoFill())
Another option as of Dec. 16 / Chrome 54
I can't get the value of the password field, but, after "a short while", I can get the length of the password by selecting it, which is sufficient for me to enable the submit button.
setTimeout(function() {
// get the password field
var pwd = document.getElementById('pwd');
pwd.focus();
pwd.select();
var noChars = pwd.selectionEnd;
// move focus to username field for first-time visitors
document.getElementById('username').focus()
if (noChars > 0) {
document.getElementById('loginBtn').disabled = false;
}
}, 100);
The workaround specified by Adam:
... detect the background color change that Chrome makes to fields that it has auto-filled. Chrome colors the background of auto-filled fields yellow, and this change is always visible to Javascript even when the value is not. Detecting this in Javascript lets us know that the field was auto-filled with a value, even though we see the value as blank in Javascript
I did like this:-
getComputedStyle(element).backgroundColor === "rgb(250, 255, 189)"
where rgb(250, 255, 189) is the yellow color Chrome applies to auto filled inputs.
I have found a solution to this issue that works for my purposes at least.
I have a login form that I just want to hit enter on as soon as it loads but I was running into the password blank issue in Chrome.
The following seems to work, allowing the initial enter key to fail and retrying again once Chrome wakes up and provides the password value.
$(function(){
// bind form submit loginOnSubmit
$('#loginForm').submit(loginOnSubmit);
// submit form when enter pressed on username or password inputs
$('#username,#password').keydown(function(e) {
if (e.keyCode == 13) {
$('#loginForm').submit(e);
return false;
}
});
});
function loginOnSubmit(e, passwordRetry) {
// on submit check if password is blank, if so run this again in 100 milliseconds
// passwordRetry flag prevents an infinite loop
if(password.value == "" && passwordRetry != true)
{
setTimeout(function(){loginOnSubmit(e,true);},100);
return false;
}
// login logic here
}
Just wrote an angular directive related to this. Ended up with the following code:
if ('password' == $attrs.type) {
const _interval = $interval(() => { //interval required, chrome takes some time to autofill
if ($element.is(':-webkit-autofill')) { //jQuery.is()
//your code
$interval.cancel(_interval);
}
}, 500, 10); //0.5s, 10 times
}
ps: it wont detect 100% of the times, chrome might take longer than 5 seconds to fill the input.
Chrome's intended behavior is that an auto-filled password has an empty value in the DOM until the user interacts with the frame in some way, at which point chrome actually populates the value. Until this point any client side validation or attempt to ajax submit the form will see the password as empty.
This 'populate password value on frame interaction' behavior is inconsistent. I've found when the form is hosted in a same-origin iframe it only operates on the first load, and never on subsequent loads.
This is most evident on ajax forms where the autocomplete password populates on first load, however if that password is invalid and the ajax submission re-renders the form DOM, the autocompleted password re-appears visually but the value is never populated, irrespective of interaction.
None of the workarounds mentioned such as triggering blur or input events worked in this scenario. The only workaround I've found is to reset the password field value after the ajax process re-renders the form, e.g.:
$('input[type="password"]').val("");
After the above, Chrome actually autocompletes the password again but with the value actually populated.
In my current use case I'm using ASP.NET's Ajax.BeginForm and use the above workaround in the AjaxOptions.OnSuccess callback.
$element.is("*:-webkit-autofill")
works for me
With Angular, the new behaviour in Chrome (only allowing autofilled values to be read after the user has interaction with the page) manifests itself as an issue when you're using Angular's validation functionality in certain scenarios (for e.g using standard method/action attributes on the form). As the submit handler is executed immediately, it does not allow the form validators to capture the autofilled values from Chrome.
A solution I found for this to explicitly call the form controllers $commitViewValue function in the submit handler to trigger a revalidation before checking form.$valid or form.invalid etc.
Example:
function submit ($event) {
// Allow model to be updated by Chrome autofill
// #see http://stackoverflow.com/questions/35049555/chrome-autofill-autocomplete-no-value-for-password
$scope.loginModule.$commitViewValue();
if ($scope.loginModule.$invalid) {
// Disallow login
$scope.loginModule.$submitted = true;
$event.preventDefault();
} else {
// Allow login
}
}
Although this is working for us so far, I would be very interested if someone has found another, more elegant work around for the issue.
var txtInput = $(sTxt);
txtInput.focus();
txtInput.select();
This solution worked in my case.
Using jQuery 3.1.1.
If you want make input to be seen as fulfilled, try to trigger blur on it:
$('input[type="password"]').blur();
The autocomplete feature has successfully disabled.
It Works!
[HTML]
<div id="login_screen" style="min-height: 45px;">
<input id="password_1" type="text" name="password">
</div>
[JQuery]
$("#login_screen").on('keyup keydown mousedown', '#password_1', function (e) {
let elem = $(this);
if (elem.val().length > 0 && elem.attr("type") === "text") {
elem.attr("type", "password");
} else {
setTimeout(function () {
if (elem.val().length === 0) {
elem.attr("type", "text");
elem.hide();
setTimeout(function () {
elem.show().focus();
}, 1);
}
}, 1);
}
if (elem.val() === "" && e.type === "mousedown") {
elem.hide();
setTimeout(function () {
elem.show().focus();
}, 1);
}
});
To me none of this solutions seemed to work.
I think this is worth mentioning that if you want to use it for CSS styling you sould use -webkit-autofill property like this:
input:-webkit-autofill~.label,
input:-webkit-autofill:hover~.label,
input:-webkit-autofill:focus~.label
input:focus~.label,
input:not(.empty)~.label {
top: -12px;
font-size: 12px;
color: rgba(0, 0, 0, .4);
font-weight: 600
}
My solution comparing my css to the chrome autocomplete color...
$('input, select, textarea').each(function(){
var inputValue = $(this).val();
if ( inputValue != "" || $(this).css("background-color") != "rgba(255, 255, 255, 0)") {
$(this).parents('.form-group').addClass('focused');
}
});
I tried all the solutions and wasn't working for me so i came up with this.
My problem is i have an input that move the placeholder top when it is filled, off course this is not working when Chrome autofill it.
Only tested in Chrome :
setTimeout(function () {
var autofilled = document.querySelectorAll('input:-webkit-autofill');
for (var i = 0; i < autofilled.length; i++) {
Do something with your input autofilled
}
}, 200);
My version is 95.0.4638.69
I'm facing a similar issue and I solved it by changing my form's name from "login-form" to another name which does not mean anything and solve it. Reason why I didn't remove name attribute is because if I remove name attribute Chrome will look up to id attribute and do the same thing.
Option using onanimationstart event (ReactJs) - Mar 22
I could avoid the needing of verifying periodically if the input was autofilled, as described above using setInterval, by taking advantage of the onanimationstart event. I don't know if it will work in every case, but definitely did the trick for me.
I'll provide a code sample in ReactJs, it may be explanatory enough to be transposed to another context.
First of all, is necessary to add in your input the onAnimationStart property, in such a way that the event is passed as parameter to your function, as following below.
<input
className={componentClass}
placeholder={placeholder}
onChange={handleChange}
onFocus={onFocus}
onMouseEnter={onHover}
onMouseLeave={onHover}
onBlur={onBlur}
disabled={disabled}
name={name}
value={value}
onAnimationStart={e => this.onAnimationStart(e)}
/>
Then let's proceed to the onAnimationStart function body.
onAnimationStart(event) {
// on autofill animation
if (event.animationName === 'onAutoFillStart') {
event.target?.labels[0].classList.add('grm-form__isAutofilled');
}
}
First I verified if the animation name was actually the auto-fill animation, and then I added a class to the first label of my input, this is my use case but can be adapted to solve different problems.
Just set the autocomplete attribute to username for the username field and new-password for the password field;
<input type="text" id="username" autocomplete="username">
<input type="password" id="password" autocomplete="new-password" >
You mentioned:
If you click somewhere on the page no matter where the value of the input type="password" will be filled.
Which is why I simply use $('body').click(); to simulate this first click, after which the value is available in JavaScript.
Also, I set autocomplete="new-password" on my signup form password field, so that the field is not autofilled and users have to fill in a new password.
See this Google Developers page for more information.
It's not a bug. It's a security issue. Imagine if one could just use javascript to retrieve autofilled passwords without the users' acknowledgment.

Turn off autocompletion without affecting session history caching

I would like to
(1) not show any suggestions to the user while typing in an input field.
This can be done like this:
<input autocomplete="off">
However, I noticed that this also
(2) disables the history chaching, e.g. when you go to another site and click on the history back button the input field will be empty.
You can try it here:
http://jsfiddle.net/LC53F/
Only text inserted into the first field will survive going to a new page and back again.
Is there a way to only have effect (1), but not (2)?
This solution should work, but is not ideal: just sharing an idea.
I don't think you will be able to preserve history with 'autocomplete', so let's try to fiddle out something.
Here's an idea: the history is based on input names, so you can turn off the autocompletion from other sites by using an uncommon name (but still constant, for example: 'email_fakeSuffix_194h5g48').
Then, to turn off autocompletion from this input previous values, you can change its name everytime the page is loaded (ie. append a random number). The problem is that, doing this, you will also turn off the history.
So, the main idea is to use an uncommon input's name and to change it just before submitting the form:
The value won't be saved by the browser because the name has changed
If you navigate to another page without submitting, the value will
still be set because you haven't change the name yet.
Here's an example using JQuery (you can use anything else, or even vanilla JS)
JSFiddle: http://jsfiddle.net/vse9jx3r/
HTML
<form>
<input id="input1" name="email_fakeSuffix_194h5g48">
<input name="input2">
<input type="submit">
</form>
JS
$('form').submit(function() {
$('#input1').attr('name', 'email_fakeSuffix_194h5g48_' + Date.now());
//SUBMIT THE FORM (MAY DO NOTHING AT ALL)
});
You can tell me if I'm not clear enough.
This works for me (using jQuery 1.9.1):
$(function(){
$('input[type=text]').prop('autocomplete','off');
$('#formid').on('submit', function(e){
$('input[type=text]').removeProp('autocomplete');
});
});

jQuery change event fired twice when giving focus to another control inside the change callback

A weird bug caused me a lot of headaches recently, and I've been able to dumb it down to the simplest form possible. See this fiddle : http://jsfiddle.net/PgAAb/
<input type="text" id="foo" placeholder="Change me!"><br>
<input type="text" id="bar" size="30" placeholder="Dummy control to switch focus">
$('#foo').change(function() {
console.log('Changed!');
$('#bar').focus();
});
Basically, when you change the first textbox and use the mouse to click elsewhere in the document, the change event fires, as usual. However, if you change the value, and hit the enter key to trigger the change, the event fires twice.
I've noticed the bug is only with Chrome. Firefox does not trigger the event twice, and IE does not even support the enter key to trigger change on an input.
I guess that happens because of the focus switching inside the event callback. Is there any way around this?
The focus() on other control in your change eventhandler call the change event in chrome because it unfocus "blur" your current control if the value is different.
This bug is not new, you can take a look at this bug ticket on jQuery : http://bugs.jquery.com/ticket/9335
You can work around this by disabling the change eventhandler before to remove the focus on your control.
Here a little exemple of what I want to say:
$('#foo').change(changeHandler);
function changeHandler() {
console.log('Changed!');
$(this).off('change').blur().on('change', changeHandler);
$('#bar').focus();
}
Also, you can workaround this bug with just blur your input on Enter key:
jQuery('input').keydown(function(e){
if(e.keyCode==13) jQuery(this).blur();
});