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.
Related
I'm currently working on an app that has some legacy Flash pages. We recently added a dropdown in the header that opens into a scrollable div. The header and dropdown are HTML.
Here's a wireframe to illustrate the set-up.
https://wireframe.cc/27ahkk
We ran into an issue where using the scroll wheel while hovering in the dropdown did not behave as desired.
Dropdown does not scroll
Flash content scrolls instead
I expected this was because, as part of Flash's processing of the wheel/mousewheel events, it was preventing bubbling and preventing the default action. I did some initial tests in Chrome and found that any event listeners I attached to the bubble phase were in fact not called.
My solution was to attach a wheel/mousewheel event listener to the window on the capture phase. In that handler, if the mouse is hovering over our dropdown, I call event.stopPropagation() to prevent the event from ever reaching Flash (thus allowing the default action to occur). Roughly:
window.addEventListener("wheel", function (event) {
if ($('.dropdown-selector:hover').length != 0) {
event.stopPropagation();
}
}, true);
This event is removed when the dropdown closes.
This worked fine in Chrome, and it works in IE as long as you fall back to the deprecated "mousewheel" event instead of using the more modern "wheel" event. Firefox, however, is a different story.
While Firefox supports the "wheel" event, it seems that the way in which events are sent to Flash from the browser is entirely different.
If you are hovering over the dropdown and scroll with the mouse wheel:
The handler will fire
The if condition properly detects the hover
event.stopPropagation() is called
However, Flash content still scrolls
Dropdown div does not scroll
Even stranger, if you are not hovering over the dropdown and you scroll with the mouse wheel:
The handler never fires
Flash content scrolls
This is different than the observed behavior in Chrome and IE, where scrolling while hovering over Flash will still fire the handler, but since the mouse is not over the dropdown, event.stopPropagation() is never called and thus it captures down to Flash where the event will be handled.
This is confusing to me because I attached the listener to the window in capture phase, so I should be receiving the event before anything else on the page. But in Firefox, it appears that either Flash gets the events even before window, or Flash receives a different event altogether (Flash appears to receive these events even if the JavaScript is stopped on a breakpoint in the debugger).
Does anyone have experience with Flash and Firefox and have a better understanding of how the browser sends events to embedded Flash content? Why does my strategy work in all the other browsers but fall short in Firefox? Any possible workarounds before we try to delve into the Flash code itself to work on a solution?
So I found a fix for this issue, although not entirely sure why it works. Even though Firefox supports both the "wheel" and "mousewheel" events, registering our listener to these events did not produce desired behavior. However, listening to the "DOMMouseScroll" event worked beautifully.
Not sure if this is due to some browser-specific logic and/or how our legacy Flash code handles scrolling, but it works so I'm satisifed. :)
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?
An issue in the Chrome browser (https://code.google.com/p/chromium/issues/detail?id=170631) is causing quite a few issues with functionality that I'm building for a website at the moment. In the application if an onmousemove event is triggered simultaneously as a onmousedown event it appends a class that disables accidental link following since the user is dragging DOM elements. However, if an onmousedown event is fired and there is no movement (essentially a single click) it will follow the link.
This works flawlessly on everything except Chrome, since it incorrectly interprets an onmousedown event as an onmousemove event (occurs with both JavaScript & jQuery). I thought about adding a timer to determine how long the user has held the mouse button down to distinguish the difference between click and drag, but this seems like an inefficient and potentially error prone option. Any thoughts on how I could setup a work around until Chrome fixes this bug would be much appreciated.
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.
Is there any DOM event for when the browser tab loses/gains focus? I know there are the blur and focus events on window, but they also fire when the browser window as a whole loses focus. The browser might then be still visible to the user. Of course such an event would be browser specific, but that's ok.
The reason why I want this is because I run animations that might consume quite some CPU time. When the browser tab is not visible there is no reason to continue animating. Now I know that modern browsers reduce the timer resolution of background tabs, but I could actually pause the animation, so that no CPU time whatsoever is consumed.
In case you are wondering, this is what I'm writing:
http://panzi.github.com/Browser-Ponies/
At least Google Chrome supports a webkitvisibilitychange event and a document.webkitHidden property. See the visibility API. But it seems only to fire when the shown tab changes, not when the whole window is minimized. There also seems to be a visibilitychange event for Internet Explorer, but the documentation doesn't say anything about it.
The closest thing I believe you'll find is the top answer here:
Is there a way track the focus on tab with Javascript?
Now they have exactly what was needed:
https://developer.mozilla.org/en-US/docs/Web/Guide/User_experience/Using_the_Page_Visibility_API