Hammer.js - Rotation in Internet Explorer 10 - javascript

I'm having some trouble with the hammer.js-touch-framework, to be more precise, the rotation-trigger. My code is pretty minimalistic, as you can see in this jsfiddle (I'm using jquery.hammer.js from the official hammer.js-website):
http://jsfiddle.net/kgEFs/
My main problem is, that rotation and pinch both are not triggered, only tap gets fired.
I know, other browsers might be better for web-development, but I'm interested in how I can make my object rotate, even in Internet Explorer.
Tapping on the <div> with MSIE 10 triggers the tapping event and even could rotate the object, if there was a value (you can check by simply changing e.rotation to 10). I already got the rotation-event once, but I can't reproduce how I achieved it.
Any ideas?

Related

Drag and drop issue in Chrome related to Windows scale (125%)

I have an issue with drag and drop on Chrome (v69.0.3497.100). Specifically, some of the drag and drop events are getting fired when Windows scaling is other than 100% even though they shouldn't be firing.
Check out stackblitz example, and try to drag "blue" rectangle over itself (just drag, move a little bit downwards and drop). If Windows scaling is set to 100% (browser zoom is 100% as well) then one event is fired (dragEnter) as expected (check the console). But, if Windows scaling is set to 125% (but browser zoom is still 100%) then three events are fired (two dragEnter and one dragLeave), and I expected only one event to be fired since the element was dragged and dropped on itself (as it was the case with 100% scale level).
It could be that since this is Windows zoom (and not browser's zoom) the left ("lightred") rectangle is larger that it appears, and it goes below right rectangle, and events are propagated to it, although I couldn't prove that since all elements have correct size in the inspector.
This doesn't seem to be happening in latest Firefox, IE or Edge.
Does anyone know why is this happening and how to fix it?
The more I look at this problem, the more it seems the Chromium issue. Some days ago I posted a question, then I wanted to set up a bounty for it, and then I found your one, and I believe they are interrelated: Subpixel scroll issue, can't set scrollTop properly on Chrome 69.
There are some bug reports in Chromium issue tracker related to scale-rounding problem: link 1, link 2... I also created my own bug: link 3. There should be more information but it takes too much time to research. I think we may join efforts and draw more attention to the problem, and for example if it's Chromium responsibility, to help them with clarification and prioritisation.
I have the same problem with Version 76.0.3809.100 (64-Bit).
And I offset the image to compensate for the strange offset that I get in your stackbliz example too.
But with scaling 200% I need to multiply my calculated dragImage offset by 4 !!!
On 300% it's at 9
On 350% it's at 12.25
Do you see the pattern ???!
I'm afraid of my hack/fix for this problem. Not sure if it's just on windows, if it's just desktop. But for now I guess I will have to do window.devicePixelRatio^2 so I can continue my work.
There are instances where a website has drag-and-drop features that will not work inside the Google Chrome browser.
Fixing Drag-and-Drop
Enter the following into the Google Chrome Top search bar.
Chrome Flags: chrome://flags/
Type Touch into the search bar and set the following options to Enabled.

How to prevent IE from whole-page-zooming when someone "pinches" on touch screen?

I have an element with a line graph in it that I want to be able to handle pinch zooms, so the user can zoom in or out on a certain part of the graph. This works great in every browser except IE11, where instead of zooming the element, it zooms the entire page.
Is there an obvious way to prevent this kind of functionality, so IE allows for pinch-zooming on specific elements? Or maybe there's some way to capture the pinch event, e.preventDefault(), and maybe zoom the graph manually?
I have asked a few other people to try to reproduce the issue, and it seems like it's not a problem on Windows 10... I'm on Windows 7. Could this really be platform dependent? But even if it is, maybe intercepting the events is a good approach? Any suggestions would be greatly appreciated.
Here's an example of a chart where I am having this problem:
http://demos.wijmo.com/5/Angular/FlexChartZoom/FlexChartZoom/
According to the official documentation, programmatic control of touch and gesture recognition requires Windows 8 or later.

Three.JS - Scrolling issues in firefox

I am not sure if anyone else is having this problem or not with three.js. I have a simple demo of a cube that will spin with a varying rotational velocity (arrow keys, mouse, or touch input). Everything seems to work fantastic in the Chrome browser. At work I hopped on the iMac, the textures seem to be splicing and not mapped to my geometry correctly in Safari.
I moved over to the Firefox browser on the mac and everything works, and the frame rate is decent. It just seems that for some reason when the cube gets rotated at certain angles the renderer jumps and the onscreen hud moves up and you can't see the title at the top and the stats widget moves up from the bottom of the screen. It also seems that my cube's y position jumps up at the same time. I seem to have the same problem in android on some of the mobile browsers. I was wondering if anyone has had similar issues in Firefox (on Mac?) or in mobile browsers with the rendering suddenly jumping, moving the onscreen hud, etc
EDIT: I have figured out the problem. I still do not have an ideal solution. I created a copy of my demo and tried commenting out my keyboard handling code and to my surprise the issue still existed. Apparently firefox is scrolling the window slightly up and down and the keyboard handler included in the THREEx library does not disable the default behavior of the up and down arrow keys in Firefox. In chrome there is no room to scroll my window and I simply make my renderer the size of the window. I do not see why firefox is scrolling.
I experiment the same problems on Firefox in Mac on your example.
The jumps on the rendering are due the garbage collector (poorly implemented on Firefox). You are allocating memory on each "animate" function.
Instead of creating new Vector3/Matrix4 for your rotation, use global variables, so you just create those objects once.
Besides, instead of using KeyboardState, and executing those 'State' functions on each animate call, you should use a KeyboardListener, which will execute your code just when something changes (and not all the time).
You should take a look to this example: http://mrdoob.github.com/three.js/examples/canvas_geometry_cube.html
The problem was that for some reason in Firefox (not Chrome) there is room to scroll even though the renderer is set to the window size, so Firefox was scrolling when using the arrow keys. To fix this, I edited two functions in THREEx.KeyboardState.js adding a preventDefault() to prevent the arrow keys from scrolling.
Here are the needed edits:
this._onKeyDown = function(event){
event.preventDefault();
self._onKeyChange(event, true);
};
this._onKeyUp = function(event){
event.preventDefault();
self._onKeyChange(event, false);
};

Get Firefox contenteditable drag-and-drop cursor position on dragover/drop event

I'm trying to put together an image uploader. I want to upload images into a contenteditable area with drag-and-drop.
As I drag the file, I see the cursor moving - unless e.preventDefault() was called.
In Chrome, there is a function document.caretRangeFromPoint(x, y) to convert coordinates to cursor position (range).
As far as I'm reading, there is no such in Firefox. (please prove mo wrong)
Is that moving cursor which I can see to be catched somehow? Maybe in the dragover/drop event? As for my experiments, it is not accessible as a range in the dragover event. I wish I was wrong.
I bumped into the answer in the following thread (after having my own caretPositionFromPoint implemented, damn it :D)
In Firefox, you can simply access it in event.rangeParent and event.rangeOffset respectively.
Hope this saves someone's butt.
The standards-based method that all browsers will hopefully eventually support is document.caretPositionFromPoint() and Firefox doesn't support it yet. There is an open bug on it though:
https://bugzilla.mozilla.org/show_bug.cgi?id=654352
Update
Firefox has supported this since version 20.

Flash: Using mouse wheel events in full screen mode (Windows and Mac)

Although Flash has a mouse wheel event (MouseEvent.MOUSE_WHEEL), it comes with quite a few problems.
The first is that the event is not yet supported on the Mac. So there are a bunch of solutions, all of which (basically) capture the mousewheel (or DOMMouseScroll) event in javascript and pass it into the flash app. Luckily, under all the Mac browsers I tested, this also works when flash is in fullscreen mode.
Problem 2 is that flash ignores mouse wheel events with small "deltas". For example, Microsoft's IntelliPoint Mice with "Smooth Scroll" causes this problem. A solution to this is the same as the solution for the mac... i.e. capture the javascript mouse wheel event in the browser and pass it to the app. The issue is that of the browsers in windows that I tested (firefox, ie, safari, and chrome), they don't seem to capture this event when flash is in full screen mode. Does anyone know why or how to fix that?
I currently have a hybrid solution that always takes events from javascript (in non-fullscreen or fullscreen mode) except when it's in fullscreen mode on Windows (at which point it takes them from the flash mousewheel event). So the only times it fails is in full screen mode on Windows with a mouse that has small deltas. Anyone have a full solution? Or just a better one?
It's a know issue on adobe's JIRA. You need to wait'em to fix it, or use another event instead MouseEvent.MOUSE_WHEEL. It's not working on windows because the flash player implementation is completly different in windows from mac and linux. Mac and Linux uses GTK to implement the plugin Handle. On windows it uses a Win32API Common HWND, which steal focus on full screen mode, causing the non dispatching of scroll events on the browser. On Mac and Linux, GTK just stretch the plugin size into desktop's size, and don't do a real fullscreen. It's a GTK behavior inside these systems. Nothing can be done.
Your solution is one of the best. Only one is better - don't use mouse wheel :(
Adobe should do something with it (and with support for other controllers).
MouseEvent.MOUSE_WHEEL seems to work fine on mac since Gala beta and 10.1 final. i can trigger mouse wheel events using the magic mouse and track pad in both Safari and Chrome.
Pixelbreaker's MacMouseWheel has given me successful fullscreen scrolling on a mac, but I haven't used it in a while (on Safari 5 for example).
The downside is that it captures events for the whole page, so you will lose scrolling for the HTML even if the flash element is only a little box on the screen.
But you could basically switch between what you've built already, and what he's using in the macmousewheel.js when you've enabled full screen.
Hope that helps, good luck.
You could try using the simple AS3 class MacMouseWheelHandler at http://blog.earthbrowser.com/2009/01/simple-solution-for-mousewheel-events.html which makes it so you don't have to integrate with Javascrpt. It injects the Javascript right from Actionscript.

Categories