OK, I'm trying to reset the activeElement from the middle of the page so that the tab key would start from the top like, the same way as the page is just refreshed.
For that purpose (tested in FF and Chrome) I'm trying to use document.activeElement.blur() (from the browser console). As result, the selection of the <a href></a> gets visually removed (nice).
Also,running
document.activeElement after running document.activeElement.blur()
from console shows
<body class="ng-tns-0-0">
which looks good (the activeElement is body now?)
However, if I close the console and hit the Tab key, the focus appears on the next to the previous a href - Not to the link that is focused on page load + Tab key.
Why and how to fix that behavior?
The question appeared from the accessibility point of view, as the significant part of the page gets rendered with another content. The tab key needed to start over, like for a new page.
In fact, you shouldn't use blur() ever, and this method shouldn't even exist.
After having called blur(), you have no control of where the focus goes. It may go in menu bar, toolbars, or even go totally outside of the browser and/or become completely unrecoverable without a mouse.
The behavior you observe with firefox and chrome isn't standard, isn't specified anywhere, may depend on OS and/or browser settings, and you don't have control at all on it
The safest solution if you want to go back to the first element of the page is probably to focus that first element, rather than calling blur() and hope for the best.
In order for any application or website to be keyboard accessible, the focus must always be under control, i.e. you must always know exactly where it is. As the method blur() doesn't specify where the focus goes next, you lose control of the focus when using it; so you should never use it. As far as I know, it has probably no legitimate use.
In my application, clicking on the caption div for a window minimizes it, and clicking on the body of the window focuses the input control. However, if the user selects some text, the browser still fires the click event. How do I distinguish between click events that eliminate a selection and those that form a selection? I tried checking window.getSelection().isCollapsed but that is still set to true in the handler if there was a selection and the click clears the selection.
Is there a correct way to do this?
EDIT: This might be a Chrome bug. The behavior works exactly as I want in Firefox. See the example code here https://jsfiddle.net/tL3obf7q/
EDIT 2: Chrome bug after all! https://bugs.chromium.org/p/chromium/issues/detail?id=289763
So I have a weird issue in IE 10: I open a JQuery dialog with a drop down and a textbox.
I am opening the dialog in an enter jquery event on the page that opens the dialog window.
My issue does NOT happen when it is the shift event though the code called is the same.
When opened with enter though the drop down list will close as soon as you click it, the mask on the textbox is not showing its graphics and if I select the textbox and press tab the focus keeps snapping back to the textbox.
HOWEVER when I select another program and then IE again, while in the dialog, it starts to work normally again...
When I turned off the mask (jquery.maskedinput-1.3.1.min.js) instead I could not tab away from the drop down list and still could not use clicks on it.
Also without the mask switching to another program and back did not help.
All my code works exactly as it should in FF and Chrome. Also its all normal JQ (Version 1.9.1 and the ui version 1.10.1) except the mask.
Weirdest thing I have seen yet with IE.
Fixed by moving focus to another field before opening the dialog. No idea why.
This is a tricky one to describe but here goes.
A select control with a size > 1 is positioned in the browser down the bottom of the screen such that there is a scrollbar present in the body and only the first item in the select control is visible (the other items are there but you need to scroll the page down to see them). There is an onclick event in the select box or any parent above it but such does not fire when the select is clicked the first time. What happens is that chrome automagically scrolls the page to show all the items in the select, but apparently forgets to pass the click event to the handler.
This behavior only seems to occur in chrome. (works fine in FF and IE)
Chrome developers are notoriously slow to fix bugs and especially given the obscure nature in this case, I suspect it will never be fixed.
Using setTimeout in the onfocus event (in addition to the onclick event) solves the problem as the onfocus doesnt seem to be inhibited. However I would like to find a less hacky solution if there is one.
Ideas?
I'm currently toying around with some autocomplete form fields, and am finding it very hard to inspect the generated drop down items. As soon as I click on the "inspect element" button or try to right click on the dropdowns, the original autocomplete input runs an onclick event (or something that triggers on a focus change) and hides, deletes or otherwise modifies the element I was trying to inspect.
Is there a way to work with the debugger so that the mouseclicks and other commands I give to it don't get intercepted by the script I'm trying to debug?
I currently have this kind of problem on both Firebug and on Chrome's inspector. The only solution I can think right now would be setting some smart breakpoints inside the appropriate event handlers but that is hard to do if I don't know what event handlers to look for or where they are hidden in the original code...
You could set a breakpoint and inspect after it is triggered, I have noticed that freezes the DOM.
You need to use breakpoints. As far as tracking down what's happening where, Chrome's "Call Stack" window can be very helpful.
Cheers
In Firebug you have a Break on next item in Script panel. Since Firebug 1.10, there's a keyboard shortcut for this: Ctrl+Alt+B on Windows (it works even if focus is in the page, not in Firebug).
You'll probably need to have Script panel focused in Firebug since this is a shared shortcut for Break on... which differs in each panel.
It generally freezes the DOM although it's not 100% reliable.
It's also not ideal because it will stop at any JavaScript execution, and will not be helpful if there is some aggressive polling in the background, or global capturing of keyboard events. Anyway it's still better than nothing.
Chrome pauses Javascript execution on F8; it took a bit of repetition but pressing F8 at the right time prevented JS from defocusing the element.
If you are having problem selecting the element, you can try cmd + shift + c on Mac to select the element without right clicking it.
If its DOM manipulation problem, you might try to force state on the input element by right clicking on the element in the Elements panel and set force state to focus.
Open the docked DevTools first (the undocked approach will not work due to the OS limitations.)
Once the autocomplete box is displayed, right-click it and select "Inspect Element" in the context menu. The focus will move to the DevTools but the autocomplete box will still be shown (this worked for me on Linux, tip-of-tree Chromium, M25. Your mileage may vary.)
/**
* Utility to freeze actual DOM state, for example dropdown menu
*/
function easyBreak() {
function doBreak() {
// put breakpoint here to freeze actual dom and write to console easyBreak()
// you have 3 seconds to get to desired state
var a = 0;
}
window.setTimeout(doBreak, 3000);
}
You could use DOM breakpoints.
I'm having a similar case here : I want to inspect dropdown items that only show when the input has focus.
On Chrome, I right-click on the parent element and choose Break on > Subtree modifications.
It will pause - like it does with JS breakpoints - anytime the DOM changes within that parent. You can then inspect the children while the DOM is frozen.