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?
Related
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.
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.
I have to debug a menu that "Wiggles" when the user mouses over each element in it. This only happens in Internet Explorer. In other browsers if I'm looking at markup it will update as events are triggered or styles applied and you can see that in the style trace. IE does not do this, if it can I'm unaware. Is there any way to see updates to the styles/markup in explore, live in the markup/style view, while interacting with the page?
This sounds very much like an old white-space bug. Is the menu formed from the Unordered List? If so, do you have carriage returned between each list item (ie each <li></li> is on a separate line)?
If so, try removing all the whitespace (so all list items are on a single line).
So my problem was that the menu items would "wiggle" when the user would mouse over each item. The problem was that this only happened in Internet Explorer. Where other browsers will let you watch a "live" view of the markup and styles, IE only allows you to refresh that view by clicking on a button above the view or using F5. That complicates things because if your moused over the browser F5 will reload the page. While if you mouse out and refresh the menu item has lost it's change by the time you click the refresh button.
My solution was to isolate the functions called by the mouseover and mouseout events, which were 7 character dynamically named garbage. Once I had what they were being called I could call them and trigger the mouse over and out actions on my own. Then I was able to refresh the markup view and see the styles, applied styles, that were changing.
Turned out that the on mouse-over event added a style that stripped the padding on the top and bottom of the element. In every other browser the box model is rendered so that this didn't matter. In IE it meant that everything would "wiggle" as you moved though the menu.
Gotta love legacy code... and IE.
I've noticed a strange issue with how Chrome handles javascript focus event. The fact is, it continuosly triggers focus event, even if it occurs only once. I've made a bit of research here and found questions where people run into the same issue when using alert(). When they close the alert window, the focus returns to their inputs and a handler triggers again and again. In my case, the problem is different, as I am using console.log(), and from time to time I get the same log 2 or even 3 times. I've noticed it usually happens when I clear the console, and then focus on an element. When I try to repeat it, it does not occur any more.
The scenario:
Clear console
Focus on element (2 or 3 console messages)
Focus on other identical element or unfocus and focus again on the
same one (no problems)
Clear console
Focus on element (2 or 3 console messages - the problem is back!)
I've created a jsfiddle, please check it out:
http://jsfiddle.net/ffuWT/3/
The question is, what is the reason for this issue and how can I work around it?
Creepy how these things can happen. I've run into this exact issue at work today, but have quickly written this off suspecting dodgy event listening and propagation in a 3rd-party plugin (jQuery customInput). I'll double-check your jsfiddle tomorrow.
I'm unable to recreate your exact output on my currently available setup (Chrome v17 on a Mac) but I do have a theory to share. In your scenario and in Ben Lee's comment the consistent part is shifting focus to another window (console in your case).
Check out http://www.quirksmode.org/dom/events/blurfocus.html under "Window + focusable element":
If the window is sent backward while a focusable element is focused,
blur events should fire on both. If the window is brought forward
again, focus events should fire on both.
And next, in the compatibility table it's noted that
Safari Windows fires two focus events.
Maybe Chrome finally got this "feature" too, coming from the Webkit family and all?
I was able to recreate the problem (using your jsFiddle) and from what I can see it only occurs when you click the select without having focus on/in the result frame.
Click within the frame but not on the selects before you click to expand one of the selects and you´ll only see one line logged.
You can also append /show to the jsFiddle URL to view the result in a separate window.
It seems like focusing the window by clicking on a select control triggers the event multiple times.
Open this demo and unfocus the browser window (by clicking the desktop, taskbar or another window) and then click on one of the selects to expand its options and view the console.
Using Chrome 17.0.963.79 m.
I have a lightbox-like div which appears over pages to present scrollable content. In FF, IE, and Chrome, allowing the user to scroll the lightbox with the arrow and pagedown/up keys is as simple as assigning it a tabindex and calling .focus().
In Opera, .focus() does nothing and tab/arrow/page keys will continue acting on whatever tabstop elements are in the background page.
Here's a fiddle to illustrate the problem: http://jsfiddle.net/9W943/5/
I have seen many examples of how to focus a div, but none seem to acknowledge that the tabindex approach doesn't work in Opera. Is there any way I can force Opera to focus the lightbox? Failing that, what's the best workaround - listen for key events and then "manually" scroll the lightbox? (Or can I redirect the events?)
I have tried calling .click() on the lightbox, and creating+dispatching a fake click event - since keyboard scrolling works correctly after you click it - but neither worked.
Also I am very curious why it's not standard for non-input elements to be focusable, since they can and do receive keyboard events! How do you define a focused element, if not as the element which can be interacted with via the keyboard?
This is a known bug (internally DSK-269802) - unfortunately there is no nice workarounds that I know of :-/
I ran into this problem yesterday myself and will give the bug a "bump" - perhaps we can fit it into some on-going development work. I'd recommend that you ignore the bug and just code as if it worked in Opera, because some day it will.