I would prefer to keep it, but it always ends up hiding the information I was looking for
You can't even use ESC to get rid of it, you have to type something and delete it
Related
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.
After some update of chrome or maybe moving my script to a new computer I am no longer able to use a very simple macro for sending the ↑ and ↓ arrow keys.
My code:
!w::send, {Up}
!s::send, {Down}
I attempted adding return to the end of the line and reformatting but only got the behaviour for ↓ regardless of combination. even more odd was that the following code also made the page scroll down
!w::send, {Up} return
and
!w::send, {NumpadUp} return
I am more than a little confused how such a simple macro is not functioning. in only google chrome but fine in other applications. My current thought is that it may overlap with some active extension but I am only seeing a possible conflict with a smooth scrolling extension that shares the usage of the alt key. This however was active last time the macro was functioning and worked to enable smooth scrolling. Attempts with the extension disabled have not produced different results.
I have also altered the key trigger to be just "w" and this yields no result in chrome. Yet the original code functions within text fields in chrome. I think this is mostly an issue with google chrome but I cannot understand why sending the key does not function despite it working when pressing the actual direction keys.
EDIT: So another round of troubleshooting I tried switching to a guest user and the macro functions. there must be an extension that is taking priority over the macro functions. What remains confusing that is it does not appear to have any relation to which key combination I attempt to trigger it with. I will have to start blank and progressively re-enable everything to find out more about the interaction.
I'm trying to make an extension for Google chrome which requires me to be able to identify the currently selected tab. I did this with the chrome.tabs.onSelectionChanged method, however when I switch windows this isn't fired. I plan to use chrome.windows.onFocusChanged to detect when the window changes then use the chrome.tabs.getSelected method. However the problem is that chrome.windows.onFocusChanged seems to be fired more than once. If I'm not mistaken, it returns window -1, then the first window created (usually 1), then the current window. If the first window is selected then it's fires -1, then 1.
Am I using the right method here? Is there a better way of doing this? If I stick with it I might need to keep track of how window changes which is a bit messy.
Kinda worked on my own solution for this. For anyone interested in doing something similar, what I did instead was to use the onFocusChanged as an indicator that there is a window change happening which then starts a requestListener. Using content scripts, I sent a request to the extension whenever there was a window.focus event indicating that the focus is already on that window. The requestlistener then just removes itself. Unfortunately this approach requires all tabs to send requests every time they get focus. Some more tweaking to fix that I guess but for the mean time I think that suffices since sending requests every time there is a change of focus doesn't seem to eat up that much resources.
this is insanely annoying problem:
AS3 full screen application based on ADOBE FLEX 4, text field. User types something in text field, and then starts clicking backspace many many times to remove what he just wrote, and for some reason, instead of removing characters from text field it tells browser to GO BACK and user navigates away. Why?! Please, please help, this is so terrible. My users are losing important unsaved this is data while using my application!
i am using safari browser
PLEASE HELP.
Wow, this is terrible, I am so irritated, it happens every single time
It is possible that the focus is lost from your text field when hitting the backspace multiple times (check if you are firing some events on the text field that may cause this), which causes the main window to take focus and trigger 'Back' on the browser.
The root of the problem is that the browser carries out keyboard shortcuts REGARDLESS of the flash app having the focus or not. From what I heard this problem does not exist on Safari's for Mac, only Safari for Windows.
I would check to see what browser you are in and then create a popup saying you this app does NOT work on Safari browser ON windows.
Scratching head*
Well maybe if HAD to solve this, I would use the ExternalInterface to interact with Safari or javascript to PREVENT the history back button from getting applied. So it won't go back to an old page. That is what I would look into.
In an Access (2002 / 2003) data-bound form, a turn of the mousewheel moves to the next/previous record, even if the cursor is inside a multiline text field or a listbox. This is a major annoyance to users and cannot be turned off easily.
I recently discovered a DLL called MouseHook (http://www.lebans.com/mousewheelonoff.htm) which can effectively block this mousewheel behavior and replace it with more expected behavior.
However, when an external ActiveX control is added to an Access form, this module does nothing. For example, I have a form with a FlexGrid control on it, and it can contain a lot of rows. When a user tries to scroll in there using the mousewheel, Access again simply goes to another record instead, even with MouseHook DLL loaded.
Is there a solution like MouseHook DLL but which also works for external ActiveX controls? Or is the source code of the MouseHook DLL available so it can be modified to deal with controls like FlexGrid?
PS: I wanted to ask the author of MouseHook DLL, but he is currently "on a hiatus" until June 2009.
If you really have to alter the UI and change how the user expects the mouse wheel to work, I would actually recommend just disabling it rather than altering how it scrolls. While it's scrolling may seem odd to you, it is how the program works. What would you do if you had to read PDF's all day, and then one day one person decided that the way the mouse wheel scrolling worked wasn't good enough and changed to so it defaulted to huge jumps or horizontal or whatever. Yes, it may have been a better solution, however it is annoying to the user because it doesn't do what it is supposed to do.
Why are you using a flexgrid in Access? To me, this is a read flag that you likely are approaching the project with an Access-hostile point of view, since you seem to be choosing non-native controls to do things that are almost always much more easily accomplished with Access's native controls.
Hook the flexgrid, intercept the WM_MOUSEWHEEL message, ignore it and call your intended behaviour.
Not a direct answer to your question, but the way we deal with the mouse wheel movement is to prevent accidental changes of records after the user has started editing. When the user opens the form, the wheel moves the records willy-nilly as normal. As soon the user edits something on the field, and then moves the mouse wheel, the BeforeUpdate event fires, which causes our code to put up a prompt saying they must save the record first. We have a save button which the user must explicitly press to supress the warning in the BeforeUpdate event.