I've got a pic viewer that uses the mouse wheel to zoom. Works fine except in Opera, the wheel scrolls the page first, then fires the wheel event, which is less than desirable (since now the picture has moved up or down the page).
So, I want to turn off the body scroll while the viewer is active. Shouldn't be too hard, right?
Does the JavaScript that scrolls also call event.preventDefault()? This should work, though I haven't tested it recently myself.
possibly this might work?
body {
overflow: hidden;
}
Related
I'm at a loss as to what is going on here.
Please refer to the CodePen: https://codepen.io/ilmiont/pen/jJjgPw?editors=1111
Swiping with a touchscreen should smoothly transition the screens up and down, using the "smooth" scroll behaviour.
This does work exactly as intended with Chrome.
Firefox... just doesn't scroll. Yet the touch events are being fired, and "Next" / "Previous" is being logged to the console. But the scrollIntoView(...) call does nothing when invoked with {behavior: "smooth"}.
If you click the button, the scroll behaviour is changed to auto (no smooth scrolling)... and this works without any issues in Firefox.
What have I missed? Why is Firefox not scrolling at all when smooth scroll behaviour is used, even though it seems the swipes are being detected correctly?
A further oddity: the demo doesn't work in Chrome in CodePen either. Copy the HTML/CSS/JS into a new document (right-click CodePen viewer, "view frame source") and run directly in the browser, and it works exactly as intended, with smooth scrolling within the pages.
I think I must have missed something, and the CodePen issues in Chrome are interesting, but I just can't see what right now.
Chrome... just works... except in CodePen.
Firefox... everything looks like it should work, but the scrolling never occurs.
This has taken me far too long to figure out, but here's the solution which finally works:
Use passive event listeners!
In the original pen, I was doing {passive: false} and then calling preventDefault(...) on the touchstart and touchmove events.
It turns out, that this isn't necessary to achieve the desired effect.
Using the passive listeners results in everything working as intended in Firefox.
I still consider the original behaviour is odd; further investigation revealed there seems to be a timing issue in Firefox. In the swipe(...) method, adding a 250ms timeout to the dispatchEvent(...) call results in everything working as intended also – it seems as though the touch handlers can continue to block/throttle scroll events past when they should have been removed.
Will keep investigating but I have a solution for now.
(Edit – forgot to mention, when using passive listeners, also set touch-action: none on the target.)
I'm currently working on a website with Object horizontal rotation features. So let's say the first image you see is the front of an object, then the second image is the side and the third the back, the fourth the other side and the fifth the front view again.
In my case, I have in total 24 images of an object, which means there's a 15 degree angle difference between each picture.
Right now I'm trying to make the rotation more smooth. It works perfectly on any browsers if I use my mouse. However, things start to go wrong if i use my touchscreen instead for browsers like Microsoft Edge.
The problem on Edge is that, if I try to swipe the object to the right, it somehow triggers the "go back to previous page" feature in Edge. It's something I could fix with simple javascript code when I'm using Chrome. The code looks like this:
$(".reel-holder").bind('touchstart', function(event) {
event.preventDefault();
event.stopPropagation();
});
Another problem when swiping on Edge is that, the rotation is rotated by picture. No matter how I swipe on the touch screen, it only goes to the next/previous picture.
How can I fix this problem with Javascript/JQuery?
iS THIS EGG
This can be achieved with the touch-action CSS property. For each element whose gestures you want to prevent Edge from handling, set touch-action to none. Alternatively, you could set touch-action to none on a common ancestor, or, if you want to prevent Edge from handling any gesture, set it on the body.
If you only want to prevent Edge from going back to the previous page, by swiping, but want Edge to handle other gestures, you could set touch-action to pan-right pan-y pinch-zoom.
Example:
.reel-holder {
touch-action: none;
}
With CSS this worked for me
I used
html, body {
width: 100%;
height: 100%;
margin: 0;
overscroll-behavior: contain;
}
https://developer.mozilla.org/en-US/docs/Web/CSS/overscroll-behavior
In the following fiddle, there is significant jitter while scrolling. The jitter is noticed only in Safari on Mac, while Chrome and Firefox scrolls the page smoothly.
https://jsfiddle.net/saptarshi17/akxuLL9x/
The jitter is a result of applying parallax effect on the first paragraph. The parallax is implemented by dynamically calculating the top css property triggered by scroll events. I am noticing this on Mac OSX El Capitan, not sure about Windows.
So far, I tried:
Added a mousewheel event-listener in addition to scroll as per this accepted answer on SO.
Tried wrapping the css("top", ...) function call within requestAnimationFrame()
Changed div from relative to absolute to avoid costly reflows.
Added preserve3d property to "hardware accelerate" position calculation as per some comments somewhere on SO.
Since 2 and 3 haven't helped, I assume the core issue has much to do with Safari's scroll implementation and less about frame-rate optimizations. There is a delay Safari's predictive rendering and the subsequent handler call which offsets the position. This results in 2 renders causing the jitter. While I understand Safari's intention behind the first render which works in most cases, this seems to be wrong in cases when the developer wants to override positioning. Maybe there is a way to tell Safari to disable the predictive rendering.
There is a strange bug inside my App prototype using transform:translate(...).
The Mouse Wheel is not working properly inside the transformed view:
http://foods.rk.meteor.com/
If you click the category 'Alle' you will see the searchResults inside a list.
It is not possible to scroll with the Mouse Wheel. But if you resize the browser or focus the searchInput: Everything works fine.
If you go back to the categories and resize the browser or focus the searchInput: The Mouse Wheel doesn't work anymore.
In IE11 and Firefox everything works the way I want.
In Chrome Version 41 it doesn't work
I tried to replicate the issue without meteor, but it wasn't possible for me:
http://codepen.io/anon/pen/emwbjZ
Can you confirm the issue? Do you know a workaround?
Thanks
It looks like your scrollable css isn't handling it properly.
Edit your 'scrollable' class and add in the ability to scroll vertically. This doesn't happen naturally since it is not the top level div:
.scrollable {
overflow: scroll;
}
Your current setting is auto
Very strange behaviour in Google Chrome !
I've got a grid of div , and on each of then, I add an eventListenner for mouseenter event. In my demo code, when the event is triggered the div get opacity:0.2.
$(".target_div_class").on("mouseenter", [my action ...])
Well, it's work's on every browser except in Google Chrome.
To reproduce the strange behaviour in chrome, go to my codepen demo page place the mouse pointer in front of the grid and start to resize the main browser windows quickly, you will see that some of the divs get opacity changed even if there is not mouse roll-over !
what I'm doing wrong, is an special jquery event that Chrome doesn't like ?
thank's
larry
edit -1-
I think I understand why some div receive the event.
It seem's that, when I click on a border (left or right) of the browser, Chrome keep a trace of the mouse position X and Y.
Then when slowly expand the browser width, any div that under this "start mouse position" receive the event.
It is really simple to reproduce when first the browser width is thin, and then slowly expand it, if I take a pen and place it at the mouse start position before resize, It's clear. very very strange.
edit -2-
This behaviour is only on a OS windows 8, I've just test it on a Mac , and there is not problems !
Well, I've been testing this behaviour on a couple of sites, like this one :https://devart.withgoogle.com/
made by Google professional I suppose, and the strange behaviour occurs again, I'll try to find how to contact Google Chrome team ...
I do not believe that mouseenter/mouseleave is fully supported by chrome. Chrome only simulates those functions, unlike in IE.
But, the problem only occurs when someone tries to re-size the window faster than the browser's edge actually moves and the mouse goes into the page momentarily. So, its not that unreasonable a behavior. You could always try to fix it with a
$(window).resize(function() {
//some code to reset opacity
});
See if this helps
$(".target_div_class").on("mouseenter", function(){
event.stopPropagation();
//your code
});