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.
Related
I have a seemingly simple requirement but I have been stuck for days. Can someone give me a hand?
I need a confirmation prompt if the user tried to close the pop-up window
if the user click ok to close, I need to call an ajax call
My original design is to add an onbeforeunload event handler, have it returns a string which triggers a prompt. Works perfectly.
The problem is the next part. Added a unload listener, a pagehide listener, and a visibilitychange listener - in all three cases, Chrome doesn't fire the event if the user close the window, only if I refresh the window. Firefox works perfectly. I am using a sendbeacon call which should work in these scenarios and if I add a breakpoint to pause before the window closes, the beacon is sent, so it seems like Chrome is closing the document too fast and never bother sending the last beacon, which makes the whole exercise pointless.
Has anyone face similar issues and if so, any way to work around it?
I'm struggling with the same problem.
Reading about the event on the documentation I've noticed that it is an unstable event, and moreover in the compatibility table, Chrome is set to "not supported".
But I noticed that chrome fire the event one time only.
If I close the browser and then i re-open it, the first time the event is fired, but it not work with tab closing.
For whatever reason, natively in Chrome, mousemove events that immediately follow a mousedown event are not firing or are simply ignored altogether for a small period of time (500-1000ms?) following the mousedown event.
Strange thing is that this issue is nonexistent on codepen (on Chrome too) and the code is the exact same... There's also no issues with Firefox, Edge, etc, only natively on Chrome.
Here is a codepen nonetheless. Test it for yourself.
Copy and paste this code into actual .html, .css, and .js files, and then run it in the browser directly, you'll notice that paper.onmousemove does not fire or register immediately after a window.resize event for a very small period of time.
None of this makes any sense!
Anybody have any idea what's going on? Why would it work fine in codepen (and every other browser), yet not directly in the browser?!
I have found one issue with the codepen version, which produces a very similar bug (but involves a couple extra steps in the beginning).
Create an element by dragging your mouse on the white area
Select that element by clicking it
Drag that element anywhere on the page
Resize the browser and immediately try to create another element by dragging
However, on codepen mousedown isn't firing in this case, whereas mousemove is not firing if viewed directly in the browser. Again, there is a discrepancy, which incredibly bizarre.
Update
It turns out it only happens when the developer console is open, which is why it was not happening in codepen.
This seems to be some weirdness with Chrome DevTools. The bug you describe seems to only occur when DevTools is open. It goes away when you close DevTools. It may just be a weird coincidence, but it starts logging out mousemove events immediately when the resolution label in the top right goes away.
That being said, you have a combination of onmousemove and addEventListener going on. For instance you have both
paper.addEventListener('mouseup', checkMouseUp)
and
paper.onmouseup = function(event) {}
I'm not sure if it's the cause of the DevTools issue, but this can lead to unintended consequences since paper now has two separately assigned mouseup functions. In your case, I'd just stick with addEventListener.
I have the following code, it fades elements in and out in a repeating cycle. When the tab is inactive the text within the divs piles up on top of each other for a split second before being cleared when the tab is activated again. Is there a way to stop this animation when the window blurs and start it again on focus?
(cycle = function () {
setTimeout(function(){$('#right').fadeOut(1000)},10000);
setTimeout(function(){$('right').fadeIn(1000)}, 11000);
setTimeout(function(){$('#left').fadeOut(1000)},13000);
setTimeout(function(){$('#left').fadeIn(1000)},14000);
setTimeout(function(){$('#left').fadeOut(1000)},15000);
setTimeout(function(){$('#left').fadeIn(1000)},17000);
})();
I gave a suggestion in a comment, but then remembered that that solution is not necessarily cross-browser compatible, as I had come across it before, thus the creation of my plugin.
Suffice it to say, $(window).blur() and focus do not always work as expected on all browsers. I don't remember the exact list of problems I ran into, but I know some were things like; clicking on another tab (in FF, i think) did not trigger the blur, clicking on another program would trigger the blur despite the fact my main browser window was still open and that tab had focus, it ddnt have Windows Focus, etc...
The following plugin I created might be helpful in that I've filed it down to work in "most" browsers and versions (not tested on all versions) and it functions exactly as we expect where I work. It only goes blur if the exact browser window's tab loses focus to another tab of the same browser. And of course vice versa with focus.
See jsFiddle Example usage and unminified code
Minified Plugin:
Simply Add to a js file to be called after jquery or place at top of your code
(function(jQuery){jQuery.winFocus||(jQuery.extend({winFocus:function(b){function c(a){a=a||window.event;a.hidden=a.type in{focus:"visible",focusin:"visible",pageshow:"visible",blur:"hidden",focusout:"hidden",pagehide:"hidden"}?"focusout"===a.type:this[d];jQuery(window).data("visible",!a.hidden);jQuery.winFocus.methods.exeCB(a)}var d="hidden";d in document?document.addEventListener("visibilitychange",c):(d="mozHidden")in document?document.addEventListener("mozvisibilitychange",c):(d="webkitHidden")in document?
document.addEventListener("webkitvisibilitychange",c):(d="msHidden")in document?document.addEventListener("msvisibilitychange",c):"onfocusin"in document?document.onfocusin=document.onfocusout=c:window.onpageshow=window.onpagehide=window.onfocus=window.onblur=c;for(x in arguments)"object"==typeof arguments[x]?(arguments[x].blur&&(jQuery.winFocus.methods.blur=arguments[x].blur),arguments[x].focus&&(jQuery.winFocus.methods.focus=arguments[x].focus),arguments[x].blurFocus&&(jQuery.winFocus.methods.blurFocus=
arguments[x].focus)):"function"==typeof arguments[x]&&(void 0===jQuery.winFocus.methods.blurFocus?jQuery.winFocus.methods.blurFocus=arguments[x]:(jQuery.winFocus.methods.blur=jQuery.winFocus.methods.blurFocus,jQuery.winFocus.methods.blurFocus=void 0,jQuery.winFocus.methods.focus=arguments[x]))}}),jQuery.winFocus.methods={blurFocus:void 0,blur:void 0,focus:void 0,exeCB:function(b){jQuery.winFocus.methods.blurFocus?jQuery.winFocus.methods.blurFocus(b,!b.hidden):b.hidden?jQuery.winFocus.methods.blur&&
jQuery.winFocus.methods.blur(b):jQuery.winFocus.methods.focus&&jQuery.winFocus.methods.focus(b)}})})(jQuery);
Also: #line-o 's referenced SO Question is where I was first inspired to write this plugin and I also have this plugin answer posted there. lol
Take a look at the Visibility API for current browser. You'll still need a fallback for older ones (namely IEs).
Or you might find a solution here:
Is there a way to detect if a browser window is not currently active?
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.