Please help!
Recently (probably with version 66), Chrome began displaying its autocomplete-suggestion drop-down on the initial mouse click into a search field instead of waiting until a character is typed.
How do I make Chrome go back to not displaying suggestions until I begin typing?
I have always made use of Chrome's suggestions drop-down for search fields, but I don't want or need to see a list of random suggestions just because I've clicked into an input field. I only want to see suggestions that match what I start to type (which is how it always worked until recently).
I tried disabling the "Single-click autofill" flag and even the "Show autofill predictions" flag as well, but these flags don't seem to affect the situation. Perhaps the term autofill in these flags doesn't refer to the same thing?
If anyone can help me with this, I'll be your best friend forever and ever!
Thanks for reading this.
I was having the same issue recently with a datepicker input. To get around it, I wrapped my inputs in a form and set autocomplete="off" in my form tag, as Chrome only recognizes that property for forms and not individual inputs. I added a keyup event so that if the input has text in it, autocomplete is re-enabled:
if (val.length > 0) {
$('#myForm').attr('autocomplete', 'on');
} else {
$('#myForm').attr('autocomplete', 'off');
}
You can also add an onBlur event to disable autocomplete suggestions each time you leave an input.
Related
In Material UI Autocomplete Free Solo, I noticed that the "Clear input" button is clickable, but not accessible by keyboard.
I went into the codebase to understand the reasoning behind this decision but didn't find anything. I also checked the A11Y docs but without success either... Could anyone give a little more detail about this? Was it a decision based on user testing?
Code that adds the tabindex="-1"
Testing the tabindex="-1"
Thanks :)
As far as why it's behaving the way it is, you already discovered that. tabindex="-1" means the element should be removed from the normal tabbing order but still allows the elmenet to be focused programmatically (if you call obj.focus() from javascript).
If you're asking why Material decided to not have that button focusable, #rafael is correct that that's not a stackoverflow question. Someone working for Material that happens to be on stackoverflow might see this question and try to answer it but you're more likely to get an answer if you ask them directly.
Note that WCAG 2.1.1 is often misunderstood that every interactive element on the page must be accessible via the keyboard. That's not true. What that checkpoint says is that all "functionality" of the page must be accessible through the keyboard. In the case of the X-clear button, that functionality is also available via the keyboard because when you TAB to the input field, all the text gets selected so you can either press DELETE or BACKSPACE to erase it or just start typing new text. Or you can press Ctrl (or CMD) + A to select all the text and delete it.
So all the functionality of the X-clear button is available to the keyboard user without the actual button being accessible.
Now having said that, I rarely, if ever, make a button that is clickable with the mouse not available to the keyboard user.
Initially, I can't make the Katalon Recording (Edge Extension) work with input type time with its datalist selection. The problem with this is that the Katalon Recording can't specifically click the clock icon hence it can't open the list of hours.
Finally, I tried to use type instead of click but unfortunately can't make it work. The values I put seem not to be going to the website.
Update: I added a combination of click + type still not works. I found out that it does not click the input field at all. It does nothing and just skips the input.
Not sure why type and click are not working. My workaround here is to use setText command to input the value for time.
Our app is having an issue in IE where users inadvertently hitting backspace on non-text controls is causing navigation and issues. I've been tasked to suppress the backspace. But we're an app that is required to be 508 compliant. Accessibility is important. Wouldn't suppressing the backspace hurt our accessibility? And if so, Chrome and Edge don't have this issue. Do they not use the same keyboard shortcuts?
Alt + left arrow is standard in most newer browsers for the back button.
As this works in IE as well there is still a way for users to navigate back with their keyboard.
Technically this could be considered a fail as you are interfering with expected behaviour, but I personally think that the inconvenience of having a whole form disappear trumps that so if you decided to disable the backspace key if the currently selected input is empty that would be OK.
Make sure that this only stops normal backspace behaviour if an <input> is currently selected though (or <textarea>) using something like document.activeElement.
This way users can still use backspace to go back if they do not have an input selected.
A "catch all" solution removing the need to disable backspace
One way that you can solve this without disabling the backspace button is with window.onbeforeunload;
Create a flag set to false that changes to true if any input has a value / changes are made etc.
Then use window.onbeforeunload and check the value of that flag. If it is true then show a message, false and return null so no warning is shown.
The following example should work all the way back to IE9 and fire a warning before allowing navigation.
I would encourage you to implement this anyway - it is just as easy to accidentally close the page, hit the physical back button etc. by mistake so doing this protects against all accidental navigation.
var changed = false; // change it to true if an input has a value / has changed.
window.onbeforeunload = function() {
return changed ? "Are you sure you want to navigate away? Unsaved changes will be lost." : null;
}
Edge and Chrome willingly disabled the backspace to go back in history because of the risk of unexpected data loss.
This was removed from Edge in October 2018 and in Chrome 52.
You are perfectly right to disable it as it's intended to protect your users.
I am looking for a way to place the focus on an input field, without having the keyboard of the phone shown. The same as autofocus but after the page is initialised. Not focus() because like I said I don't want the keyboard to be shown. Does anyone know a way to do that? I am working with angular 5 if it can help. Thanks.
Nevermind. I found a way using a Timeout of about 100 milliseconds. On click I put the input field in readonly, which does not show the keyboard, then after the timeout, I remove the readonly allowing the input but not the printing of the keyboard.
I have tried this in multiple browsers and have done searches for this but have not been able to find a solution.
So here is the problem. I have CHtml::dropDownLists on my page. When you tab to that you can sometimes just type to change to an option that is with in it but there are other times where you have to actually click on that before you can start typing to change. Granted once you click on it you can change it but I need to have more of a hands off mouse control.
I was curious if this was based on how the browser placed items with its DOM or if it is something with Yii.
Any thoughts, pointer, hidden websites about this would be greatly appreciated.