I've got a demo that is required to run in Firefox on a Windows 7 touch tablet. According to this, Mozilla has implemented a standardized touch API. However, this does not work on a windows 7 tablet. None of these events are triggered in FF 14.
we have to use the MozTouchMove event. But all it does is dispatch sequential events. WI.e. finger one then finger two then finger three etc.
It's difficult to even distinguish two fingers from one. I'd have to measure the distance between updates the assign my own "IDs" to each "Region". After that, to detect a two-finger drag, we'd have to make sure the parsing stays the same throughout--which if one finger goes up may "undrag" as the "second" position is overwritten by the "first" position. Trying to come up with an approach. Any ideas?
// multitouch event handler for two finger scrolling in x or y
function onTouchMove(event) {
var eventTouch = new point(event.clientX, event.clientY);
if (previousTouch.x == 0 && previousTouch.y == 0) {
previousTouch = new point(eventTouch.x, eventTouch.y);
return;
}
//filter really close touches
//in this case, assume single touch and defer to system mouse
if (previousTouch !== undefined) {
if (eventTouch.distance(previousTouch) < 6) {
return;
}
}
fingerIndex ++;
// only track every other touch to keep fingers consistent
if( fingerIndex % 2 == 0)
{
document.getElementById("finger1").style.left = previousTouch.x + "px";
document.getElementById("finger1").style.top = previousTouch.y + "px";
document.getElementById("finger2").style.left = eventTouch.x + "px";
document.getElementById("finger2").style.top = eventTouch.y + "px";
}
previousTouch = eventTouch;
}
The status document you link to is dated July 2010 - Mozilla was close, two years ago. So you are now using the deprecated single-touch API and attempting to implement multi-touch - this is bound to get ugly. The documentation actually points you to the new multi-touch API that is available since Firefox 12. This lets you distinguish the touches properly and the documentation actually explains in much detail how you would do it.
Related
I need to organise navigation like jquery.fullPage: when I scroll once - I move to next section.
I tried to use jquery.mousewheel for it, but it fails in MacOS with touchpad or trackpad or APPLE Magic Mouse: It scrolls multiple slides per one scroll.
I tried to use this solution: https://github.com/jquery/jquery-mousewheel/issues/36#issuecomment-67648897
It works fine in Chrome, but it does not in FF and has bugs in Safari.
This is simple demonstration of issue:
http://jsfiddle.net/ss5LueLx/13/
$slider.on('mousewheel', function(event) {
if (event.deltaY>0) {
slider.prevSlide();
} else {
slider.nextSlide();
}
});
I tested this statement in my SeaMonkey browser and it fails.
var delta = e.type == 'mousewheel' ? e.originalEvent.wheelDelta * -1 : 40 * e.originalEvent.detail;
Just in case, I looked at the deltaY and it works: +1 in one direction and -1 in the other, just as you determined in the other two implementations you have.
console.log(e.deltaY); // view console in FireBug
Looking at the event structure in Firebug, I can see that the event type is "mousewheel", and yet I do not see a wheelData field in the originalEvent.
And although there is a detail field, but that one remains at zero.
I would imagine that you are attempting to go to the next item only once you reach +/-3. I would suggest something of the sort to accomplish this feat:
// somewhere, initialize to zero
var current_position = 0;
// on mousewheel events
current_position += e.deltaY;
// you had a x 40 which would indicate that the limit is about 120 / 40
// if 3 is too small, you can always increase it to 5 or event 10...
if(current_position <= -3)
{
slider.nextSlide();
current_position = 0;
}
else if(current_position >= 3)
{
slider.prevSlide();
current_position = 0;
}
Otherwise you could verify that your allowScroll flag works as expected. I do not program objects that way so I am not too sure whether it is correct or not. (I use the prototype syntax which is useful if you want to extend classes.)
I'm building a web app using quo.js to handle touch events.
When the user swipes (drags) with one finger, I can use the following quo.js code to recognise this and apply a css transformation:
$$('element').swipe(function() {
$('element').vendor('transform','translate(-100px,-100px)');
});
Now what I want to do is apply the translate amount based on the amount of swipe. In other words, I need to get the X/Y coordinates of the swipe. Does anyone know if this is possible using quo.js or do I need to use a different js library?
I tried this to get coordinates but it returns 'undefined':
$$('element').swipe(function(e) {
alert(e.pageX);
});
The event object quo.js passes to the callback contains a currentTouch object holding the x and y coordinates: http://jsfiddle.net/marionebl/UupmU/1/
$$('selector').swipe(function(e){
console.log('swipe');
console.log(e.currentTouch); // Gives position when gesture is cancelled
});
Note that the swipe event only fires when a swipe gesture is completed. As far as I understood your use case it would be more convenient to use the swiping event, which fires as soon as a swipe gesture is detected and during all movements until release:
var $swipeable = $$('.swipeable'),
swipeableHeight = $swipeable.height(),
swipeableWidth = $swipeable.width();
$swipeable.swiping(function(e){
var x = e.currentTouch.x - swipeableWidth / 2;
var y = e.currentTouch.y - swipeableHeight / 2;
$swipeable
.vendor('transform', 'translate(' + x +'px,'+ y +'px)');
});
some time ago I started to write some code in JavaScript to learn it a little bit. I picked a rollin/rollout animation as 'project'. (I know about JQuery's slideDown/slideUp, but I wanted to work with pure JavaScript.)
I finished my effect, and the result looks pretty good in all major browsers except Firefox (tested versions 22.x to the latest (25.0.1)). In Firefox, the rolling (in and out) stutters while it rolls smoothly in Chrome, Opera, and Internet Explorer.
The general approach is (unsurprisingly) to have an element's style.height (or width) attribute increased/decreased several times by some pixels over a given time. To avoid calculating sizes every time the effect takes place, I calculate them one time and place them in an array (first item (0 + stepSize), last item wanted height/width). The decrease of the element's height is done by this function:
var verticalRollInWorker = function(step) {
if (step > 0) {
$(btt).style.height = stepSizes[step - 1];
setTimeout(function() { verticalRollInWorker(step - 1); }, delay);
} else {
$(btt).style.display = "none";
$(btt).style.height = 0;
// Enable roll out effect:
stateChange(false);
if (afterFullRollIn != null) {
afterFullRollIn();
}
}
}
In the particular example, I'm using 20 steps over 400ms. The step sizes in the array are rounded to integers, that's why the last step just sets 0 - to handle rounding differences.
(For convenience, I wrote my own $(element) helper, there's no JQuery involved here.)
I tested Firefox without Add-Ons, no difference.
I highly appreciate any help you can provide :)
One problem that I noticed in the above code is that you used $(btt). So, every 20s when the function is iterated, the browser needs to obtain the jQuery object. You could rather store it into a variable say 'var BTT=$(btt);' and use this BTT. Fetching jQuery object is a time consuming task.
Since you are using setTimeout(), the function will be executed every 20ms regardless of the completion of the current execution, this may also cause a drag. As Dagg Nabbit said, you could use setInterval() instad of setTimeout.
Another possible reason might be browser-reflow. I made a personalised scrollbar, and found browser reflow was noticeably greater in my FF than Chrome or IE. This depends on the size of the element, DOM tree depth, overflow property, and more...
And again use this code and see if it is fixed. reduces the subtraction into 1 code.
var BTT=$(btt).get(0);
var verticalRollInWorker = function(step) {
if (step > 0) {
step--;
BTT.style.height = stepSizes[step];
setTimeout(function() { verticalRollInWorker(step); }, delay);
}
else {
BTT.style.display = "none";
BTT.style.height = 0;
// Enable roll out effect:
stateChange(false);
if (afterFullRollIn != null) {
afterFullRollIn();
}
}
}
Further Comments can be made only after seeing a live example.
Regards.
I'm looking at the developers reference for IE10 (http://msdn.microsoft.com/en-us/library/ie/hh673549(v=vs.85).aspx) and I'm basically trying to figure out how touch works in IE10.
I have been unable to find if there is a property that tells you how many touches are on the screen. I'm basically looking for a JavaScript property of some sort that I could check.
The only way that you seem to be able to do that is to trap the MSPointerDown and MSPointerUp events and keep count of how many unique pointers you have based on the pointerId.
You can check the following section of the above document that you listed... http://msdn.microsoft.com/en-us/library/ie/hh673557(v=vs.85).aspx#maxtouchpoints
// To test for touch capable hardware
if(navigator.msMaxTouchPoints) { ... }
// To test for multi-touch capable hardware
if(navigator.msMaxTouchPoints && navigator.msMaxTouchPoints > 1) { ... }
// To get the maximum number of points the hardware supports
var touchPoints = navigator.msMaxTouchPoints;
This is for a demo... and i was just curious, can you detect if the window has been moved? Like if you move Firefox/Chrome/IE around your monitor? I doubt it, but I wanted to see since you can check for resize and focus/blurred windows.
I can only think of this (heavy) work-around, where you check if window.screenX and window.screenY have changed every x milliseconds
var oldX = window.screenX,
oldY = window.screenY;
var interval = setInterval(function(){
if(oldX != window.screenX || oldY != window.screenY){
console.log('moved!');
} else {
console.log('not moved!');
}
oldX = window.screenX;
oldY = window.screenY;
}, 500);
Though I would not recommend this -- it might be slow and I'm not sure if screenX and screenY are supported by all browsers
A potentially more optimised version of this is to only check for window movement when outside of the window combined with Harmen's answer:
var interval;
window.addEventListener("mouseout", function(evt){
if (evt.toElement === null && evt.relatedTarget === null) {
//if outside the window...
if (console) console.log("out");
interval = setInterval(function () {
//do something with evt.screenX/evt.screenY
}, 250);
} else {
//if inside the window...
if (console) console.log("in");
clearInterval(interval);
}
});
If using jQuery, it may normalise screenX/Y in this case so it's worth running a few tests on that. Jquery would use this format instead of addEventListener:
$(window).on('mouseout', function () {});
If you are moving the window in Windows OS via alt + Space, and find that windows resizes are ignored, I would recommend adding an extra level of detection via keypress events.
Re the first answer: I use the 'poll window position' in production code. It's a very lightweight thing to do. Asking for a couple of object properties twice a second is not going to slow anything down. Cross-browser window position is given by:
function get_window_x_pos()
{
var winx;
if(window.screenX)
winx=window.screenX;
else if(window.screenLeft)
winx=window.screenLeft;
return winx;
}
and similarly for vertical position. In my code I use this to fire an AJAX event off to the server to store position and size of the window so next time it will open where it was the last time (I'm probably moving to HTML5 local storage soon.) One little wrinkle you might want to cover is not generating spurious updates while the window is being dragged. The way to handle this is to register when the window has been moved for the first time and only trigger an update when two subsequent polls of window position return the same value. A further complication is for windows which allow resizing from all sides. If the left or top side are dragged, the DOM will give you a resize event, but the nominal window position will have altered as well.
Unfortunately not. The DOM is only notified about window sizes, cursor positions, "focus" and "blur", etc; anything that affects drawing. Since moving a window doesn't necessarily require any of the contents to be "redrawn" (in a Javascript/Html engine sort of sense), the DOM, therefore, doesn't need to know about it.
Sadly, no. Although I did find this page that claims there is such a thing. I tested that in IE, Chrome, and FireFox, no luck.