I am experimenting with scroll events and in a few scripts that I have looked at I found this line:
window.onmousewheel = document.onmousewheel = somefunc;
This is working as intended, the somefunc is triggered on scroll. My problem is that Chrome is triggering the function twice (obviously because Chrome is responding to both the window and the document event). I would like to know why both events are used, is it due to cross browser compatibility? If so, which browser prefer which event? I would like to choose only one of the events, but I don't know which.
if you have frames in your html, they are not included in the document, and thus the mouse wheel event won't be triggered.
Related
Browsers support touch events and might generate mouse events. Also, for a long touch the browser generates a ContextMenu event. However, in my industrial environment, I want all touch events to be handled like a click event. Is there a global setting to prevent the browser to generate context menu events? Or can I at least set the time when the browser will generate such an event?
My only solution I came up with so far is the subscribe to click and context menu events and call the same handler. However I would rather avoid this for every button in my application...
Any ideas?
There are several answers at Disabling the context menu on long taps on Android
But I think the most voted answer over there is not a good one.
Try and see if this work for you,
window.ontouchstart = function(event) {
event.preventDefault();
event.stopPropagation();
return false;
};
I need to fix an issue that will vibrate at the mouse wheel event.
It seems to be a jquery, script problem.
This is just a page that is made up of html, css and jQuery.
This is test server.
http://ivenet.co.kr/renewal/production.php
You can check it in the chrome developer tool and use the script in fulpage_10.js.
mousewheel I looked up and modified the DOMMouseScroll event. However, the mouse wheel page is still annoying.
It seens that you try to treat the scroll behavior of the page but you still allow the browser to handle it.
So, the place that you treat the mouse wheel (in your event listener) also do an event.preventDefault(); at the begining of the function.
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. :)
Is there a Javascript event that I can hook into that fires when the page is refreshed, and Safari 'jumps' back to the scroll position you were at?
It's very frustrating, as the scroll event only fires on user/touch-induced scrolls, so will not fire in this case. I need to specifically find a way to bind to that event, as DOMContentLoaded, for example, fires even before that, and the window's load event would fire too late, as that will wait for all content to load.
Reason for this is that I am checking if an element is in view (using getBoundingClientRect).
Am I missing something here? As I'm not using jQuery, but vanilla JS, I have no document.ready() to try (though judging by the source code of it, I doubt it would work).
After some experimenting, it turns out that the load /onload event on the window triggers this jump in Safari Mobile (and presumably other browsers too), so binding to that event would suffice.
I hope this helps someone!
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.