I'm playing around with the bonsai.js library, and I added a big stage to the hero section of my site. However, in Chrome, when the mouse is over the stage (between the tagline and blue button outline), I am unable to scroll down or up. In Firefox and Safari I am still able to scroll. Why is Chrome acting up?
Site: http://cainternet.herokuapp.com
I dont know the bonsai.js library, but probably it is, because the bonsai.js library uses the wheel event and stops it from bubbling in a way, that it only affects chrome. Check the web for "Event Bubbling" for about this topic and check the event usage in your bonsai lib.
Related
I am attempting to use the data received from DeviceOrientationEvents to animate (rotate) a camera in three.js using three's DeviceOrientationControls. The controls are updated upon every animation frame, and everything works as I would expect. However, if I begin to scroll, then no DeviceOrientationEvent is fired again until the inertia from the scrolling is complete.
I have confirmed that these events are not fired (or at least not dispatched) during the scroll by logging to the console from within the DeviceOrientationEvent handler. I can see the events fired regularly up until the moment I begin to scroll, then stop, and then resume firing from the moment the inertia from the scroll is complete.
Manually stopping the inertia mid-scroll (by touching the screen) also causes the deviceorientation events to resume.
I have disabled all other scroll event handlers in my script. I have made all touch event handlers passive, have tried making them non-passive as well, and have also tried disabling all touch event handlers in my script altogether.
I am fairly sure by this point that this may be a function of how the processing of the scroll thread (which operates separately to the main thread) and the processing of IMU data are scheduled/queued in the browser, so that there may be no good solution, but I'm asking here in case there is something I've overlooked in my own troubleshooting. This does not appear to be an issue with three.js or the DeviceOrientationControls in three.js, but I've tagged this as three.js just in case anybody has ever come across this problem when attempting something similar.
My unique case for having DeviceOrientationControls enabled while scrolling is that scroll drives the animation of a "camera rig" (of empty objects whose rotation and position are animated), while moving the phone around rotates the camera itself. (It's a bit like being able to turn your head to look around while moving in a railcar.)
My testing has been on an IPhone 11 Pro, with iOS 13.5.1, in Chrome iOS 84, and Safari. I have not tested on Android.
iOS has slowed down repetitive JavaScript functionality during scroll for many years now. This is to conserve battery consumption, since it has to re-render the page lots of times while scrolling, so it halts other secondary commands until scrolling is complete. See here for more.
You could create your own custom scrolling functionality without actually scrolling down an HTML page by capturing vertical swipe gestures via 'touchstart' and 'touchmove'. Or you could use a library like Hammer.js to help you.
Since I´m working on a project where I need to be able to drag objects around my canvas but also to scroll the entire page by dragging the actual canvas 'background' behind my PIXI Sprites, i followed the findings of this guy here:
https://github.com/pixijs/pixi.js/issues/2483 :
By default, the Pixi canvas/display-area cannot be used to scroll the
webpage that contains it. Which is important on touch screens. (eg. If
you use the rest of the web-page to pinch-zoom into the Pixi canvas,
you can become trapped and unable to zoom back out (or pan away),
because there's no non-Pixi-canvas area of the page to "grab" with
your pinch gesture).
To enable this functionality, I use autoPreventDefault. But this comes
with some undesirable side-effects, like scroll/pinch-zoom actions
over the canvas registering "taps" or clicks in a way that doesn't
make sense. (ie. I'm attempting to zoom or scroll the outer page at
that point, not interact with the Pixi canvas)
To work around that, I modify and compile my own custom version of
Pixi where I can apply preventDefault in a more granular way...
To get page-scrolling functionality it seems I only need to
preventDefault in the InteractionManager.prototype.onTouchEnd
function. Whereas autoPreventDefault will also preventDefault on 3
other events. (onMouseDown, onTouchMove, onTouchStart).
Leaving autoPreventDefault = false and applying preventDefault only to
onTouchEnd, gives me the functionality I need. But it'd be nice to not
have to customize and rebuild Pixi in this way every release. (Sorry
if there's something else I'm missing here; I don't completely
understand the event system in Pixi, or what else to do about this
scroll-touch problem)
So i disabled e.preventDefault() on 'onTouchStart' and on 'onMouseMove' but left it as is on 'onTouchEnd'
This works perfect on IOS devices but not on Android, the only exception being a Samsung A7 using Adblock browser (fails on Chrome).
Would really appreciate some help on this.
TLDR:
Disabling PIXI´s e.preventDefault on onTouchStart and onMouseMove works on IOS devices and lets me scroll the page by draggin my canvas around but not on Android devices.
My solution for that was to use
renderer.plugins.interaction.autoPreventDefault = false
This should work on iOS and Android.
Docs for autoPreventDefault reads:
Should the manager automatically prevent default browser actions.
Using PIXI 4.5.6.
Take a look at the docs:
http://pixijs.download/dev/docs/PIXI.CanvasRenderer.html#plugins
http://pixijs.download/dev/docs/PIXI.interaction.InteractionManager.html
Using renderer.plugins.interaction.autoPreventDefault=true should do the trick.
When I do a Google image search on my iPhone within the Safari mobile browser, it gives me this beautiful interface for flipping through the images. If I swipe left or right, it browses through the images. If I touch and move up or down, I get what appears to be the native Safari scroll function. Can anyone explain how Google does this? I'm only beginning to learn the Safari API for touch events. It seems like either you capture the touch event to attach handlers to swipe left or right or you let Safari handle the touch events natively, in which case you get the beautiful native Safari scrolling. Can anyone explain how Google captures left/right swipe but not scrolling?
There are touch-specific DOM Events. They've implemented a lot of JavaScript logic around them. Read the Safari Web Content Guideline: Handling Events Docs Also checkout out the official spec for Touch Events
A while back, I wrote a quick library to wrap some native-like gestures as HTML events JSGestureRecognizer. I don't really recommend using that library in production, but reading the source should give you a pretty good idea about how google went about listening to native Touch Events and doing complex user interfaces with them.
On iOS safari, one-finger panning doesn’t generate any events until the user stops panning. An onscroll event is only generated when the page stops moving and redrawn.
I need a way to detect real time scrolling. Specifically, I want to make a sticky menu that will also work on iOS safari. On non-mobile browsers, sticky menu can be done by switching between "position relative" to "position fixed" on the element while listening to the onscroll events. This method won't work on mobile browser because onscroll events are not continuously fired. What can I do?
Answering my own question. iOS7 now support position:sticky
Demo: http://html5-demos.appspot.com/static/css/sticky.html
I've recently spent many hours trying to come up with a practical solution for the same problem. There's no right way to do this, although there are a few decent hacks (most of them mentioned already). The problem is that JavaScript is paused while the user is scrolling. It makes sense when you consider the implications, but it makes it damn hard to implement fixed positioned element.
The best thing that I've been able to find is this wonderful post by the folks at Google. You can check out http://gmail.com in mobile safari to see it in action.
https://developers.google.com/mobile/articles/webapp_fixed_ui
Hope this helps.
I had a similar issue and bound handlers to touchstart/touchmove/touchend using jquery to detect the single finger scrolling and it worked perfectly. In my case I needed to move another element the same amount as the attempted move of another element and it updated nicely as the scroll was attempted so it ought to be suitable for your requirement.
If all you want is a sticky menu, you can save yourself some headaches by using an existing library. I've had success with iScroll:
http://cubiq.org/iscroll
At the very least, you can take a look at how this works and base your solution around that.
Happy hacking!
Old topic for sure, but I can see alot of visits here. If all you want, is a sticky menu, you can use fixed positioning. No need for iScroll there.
I'm trying to build a menu with 5 blocks that the user can spin around.
You can see a demo here: http://m.iijax.com/menu.php
Works fine on iPhone, (if a little sluggish sometimes, but that is beside the point :p ) if i draw my finger more then 90 pixels (which i set as a limit) in either direction the menu spins.
On Android (2.1, a Samsung Galaxy S) however the menu does nothing until i release my finger from the screen, I've tried adding an alert on the 2 functions that changes a bunch of classes around to spin the menu either to the right or left and they do get triggered as I draw my finger.
So my best guess is either the browser locks access to the DOM until touchEnd, or it blatantly cheats and simply shows me some kind of screenshot of the page awaiting touchEnd.
Can anyone confirm either of these theories? I've spent about an hour searching here and on google and found nothing, but maybe I haven't found the rightsearch terms.
I've tried lots of swipe and slider examples I've found however and haven't found anything that animates in real time as i draw my finger.
Would also be interesting to know if this menu works on newer Android versions.