I'd like to track the movement of the caret/cursor in a contenteditable. I'm not sure what's the best way to do this, though.
I'm currently listening for click, keydown, keyup. (keypress of course doesn't even fire for things like arrow keys or ctrl-x.)
While click works fine, the problem with keydown is that it's fired before the caret actually moves, so when I query the current document selection range, I get the old position and not the new one. But if I rely on keyup to get the updated position, it fires too late: the caret moves as soon as the key is pressed down, but the key is released an arbitrary time later.
This must be possible because things like CKeditor are able to do this. Any hints?
It's nice to read that people are talking about CKEditor :). I'm one of its developers and I haven't been working much on selection, but I'll try to help.
What I know is that we've got an internal selectionChange event. So when do we check if it changed? ... ... At least once per every 200ms :) See:
http://dev.ckeditor.com/browser/CKEditor/trunk/_source/plugins/selection/plugin.js#L39
We also check selection every time we know that it could have been changed (e.g. by the API or on keyup/mouseup or on native selectionchange - http://dev.ckeditor.com/browser/CKEditor/trunk/_source/plugins/selection/plugin.js#L554). So... pretty much all the time :) AFAIK we do some tricks, so it doesn't burn your CPU, but it's still heavy. However, if we did this, then it's the only possible way to have this working so nicely.
Unfortunately, selection handling is by far the worst task in wysiwygs world. It's so broken in all - old and new browsers. More than 75% LOC in the file I linked above are hacks and tricks. That's complete madness.
In Mozilla and Opera, the nasty business of handling key and mouse events is your only option. Not only is it fiddly, it also doesn't cover every case: it's possible to change the selection via the edit and context menus (via Select All, for example). To cover that, you'd also need to add some kind of polling of the selection object.
However, in IE (all the way back to at least 5.5) and recent-ish WebKit, there is a selectionchange event that fires on the document whenever the selection changes.
document.onselectionchange = function() {
alert("Selection changed!");
};
There is a chance that Mozilla will support it in the future: https://bugzilla.mozilla.org/show_bug.cgi?id=571294
It's not an easy task for the reasons you said. I came up with some kludge like this:
var caretInterval, caretOffset;
document.addEventListener("keydown", function(e) {
if (!e.target.contentEditable || caretInterval) return;
if (e.keyCode !== 37 && e.keyCode !== 39) // Left and right
return;
var sel = getSelection();
caretInterval = setInterval(function() {
if (sel.type === "Caret") caretOffset = sel.baseOffset;
}, 50);
});
document.addEventListener("keyup", function(e) {
if (e.keyCode !== 37 && e.keyCode !== 39) // Left and right
return;
clearInterval(caretInterval);
caretInverval = null;
var sel = getSelection();
if (sel.type === "Caret") caretOffset = sel.baseOffset;
});
There could be a small problem if someone tries to press left and right at the same time. For ctrl-X and ctrl-V, you should catch the cut and paste event, and that's actually another pain in the bollocks.
In the end, I decided it wasn't worth the effort for my purposes. Maybe you have different needs.
WRT catching the event after the selection is updated: I simply wrap my handler functions in timeouts:
editor.onkeydown = function() {
window.setTimeout( function(){
// Your handler code here
}, 0 );
};
This registers your handler to be executed in the browser's event loop as soon as possible, but after the current (eg click) event is processed. But be aware of possible races if you have other scripts modifying the content; there is no guarantee that your timeout is the next in line to be run.
Related
I would like to find unknown event listeners
So far I tried to locate all event listeners based on This post but it did not work:
getEventListeners(Element);
and
'Chrome Developer tools > Elements > Event listeners'
Are there other ways to detect active event listeners?
The reason for asking this is:
I'm building the 2D breakout game using pure JavaScript based on the tutorial from Mozilla and managed to enhance it with various features and multiple levels.
I have a set of added event listeners and also a function that removes them, so far everything works fine.
I do not have an event listener for keycode 13(which is the enter key)
The problem is that if I press the Enter key while the animation is ongoing on the canvas, it changes the behavior with increasing the speed of the ball after each keypress and ultimately it renders a different drawing.
If I don't press the Enter key everything works as intended.
The only event listener that increases the speed is a 'click' event, but that is removed immediately after the function is executed, and it shouldn't interfere with the game.
The other problem is that through the above-mentioned methods there are no event listeners found, not even the ones I added myself, albeit they still work.
I could not find anything that relates to that unwanted behavior and I would like to ask if there are other ways to view the active event listeners.
Here is the code I'm working on
[EDIT:
After realising that the bug was coming from a keydown event, adding preventDefault() solved the problem.
However, I'm not sure why did this behaviour occur when there was no e.keyCode == 13 setup in the first place and why did the preventDefault() method solve the issue.
]
My guess is the click event is giving focus to giraffe allowing it to be fired with the enter key. You can try mousedown and preventDefault to keep giraffe from taking focus:
giraffe.addEventListener('mousedown', function(e){
e.preventDefault();
giraffe.classList.remove('pulsate');
setTimeout(function(){
giraffe.classList.add('pulsate');
}, 0);
yahoo.play();
});
It seems that the bug lays in the keydown event handler (keyDownHandler). This is what was causing the unexpected behaviour.
The bug disappeared after adding e.preventDefault(); to keyDownHandler function.
Original:
function keyDownHandler(e) { //on key down
e.keyCode == 37 ? leftPressed = true : null;
e.keyCode == 39 ? rightPressed = true : null;
}
After:
function keyDownHandler(e) { //on key down
e.preventDefault();
e.keyCode == 37 ? leftPressed = true : null;
e.keyCode == 39 ? rightPressed = true : null;
End result: Nothing happens when pressing the Enter Key
Credit to #Joe Fitzsimmons for pointing me in the right direction
I am working on some javascript UI, and using a lot of touch events like 'touchend' for improved response on touch devices. However, there are some logical issues which are bugging me ...
I have seen that many developers mingle 'touchend' and 'click' in the same event. In many cases it will not hurt, but essentially the function would fire twice on touch devices:
button.on('click touchend', function(event) {
// this fires twice on touch devices
});
It has been suggested that one could detect touch capability, and set the event appropriately for example:
var myEvent = ('ontouchstart' in document.documentElement) ? 'touchend' : 'click';
button.on(myEvent, function(event) {
// this fires only once regardless of device
});
The problem with the above, is that it will break on devices that support both touch and mouse. If the user is currently using mouse on a dual-input device, the 'click' will not fire because only 'touchend' is assigned to the button.
Another solution is to detect the device (e.g. "iOS") and assign an event based on that:
Click event called twice on touchend in iPad.
Of course, the solution in the link above is only for iOS (not Android or other devices), and seems more like a "hack" to solve something quite elementary.
Another solution would be to detect mouse-motion, and combine it with touch-capability to figure out if the user is on mouse or touch. Problem of course being that the user might not be moving the mouse from when you want to detect it ...
The most reliable solution I can think of, is to use a simple debounce function to simply make sure the function only triggers once within a short interval (for example 100ms):
button.on('click touchend', $.debounce(100, function(event) {
// this fires only once on all devices
}));
Am I missing something, or does anyone have any better suggestions?
Edit: I found this link after my post, which suggests a similar solution as the above:
How to bind 'touchstart' and 'click' events but not respond to both?
After a day of research, I figured the best solution is to just stick to click and use https://github.com/ftlabs/fastclick to remove the touch delay. I am not 100% sure this is as efficient as touchend, but not far from at least.
I did figure out a way to disable triggering events twice on touch by using stopPropagation and preventDefault, but this is dodgy as it could interfere with other touch gestures depending on the element where it is applied:
button.on('touchend click', function(event) {
event.stopPropagation();
event.preventDefault();
// this fires once on all devices
});
I was in fact looking for a solution to combine touchstart on some UI elements, but I can't see how that can be combined with click other than the solution above.
This question is answered but maybe needs to be updated.
According to a notice from Google, there will be no 300-350ms delay any more if we include the line below in the <head> element.
<meta name="viewport" content="width=device-width">
That's it! And there will be no difference between click and touch event anymore!
Yes disabling double-tap zoom (and hence the click delay) is usually the best option. And we finally have good advice for doing this that will soon work on all browsers.
If, for some reason, you don't want to do that. You can also use UIEvent.sourceCapabilities.firesTouchEvents to explicitly ignore the redundant click. The polyfill for this does something similar to your debouncing code.
Hello you can implement the following way.
function eventHandler(event, selector) {
event.stopPropagation(); // Stop event bubbling.
event.preventDefault(); // Prevent default behaviour
if (event.type === 'touchend') selector.off('click'); // If event type was touch turn off clicks to prevent phantom clicks.
}
// Implement
$('.class').on('touchend click', function(event) {
eventHandler(event, $(this)); // Handle the event.
// Do somethings...
});
Your debounce function will delay handling of every click for 100 ms:
button.on('click touchend', $.debounce(100, function(event) {
// this is delayed a minimum of 100 ms
}));
Instead, I created a cancelDuplicates function that fires right away, but any subsequent calls within 10 ms will be cancelled:
function cancelDuplicates(fn, threshhold, scope) {
if (typeof threshhold !== 'number') threshhold = 10;
var last = 0;
return function () {
var now = +new Date;
if (now >= last + threshhold) {
last = now;
fn.apply(scope || this, arguments);
}
};
}
Usage:
button.on('click touchend', cancelDuplicates(function(event) {
// This fires right away, and calls within 10 ms after are cancelled.
}));
For me using 'onclick' in the html element itself, worked for both touch and click.
<div onclick="cardClicked(this);">Click or Touch Me</div>
Google Chrome has the key binding Ctrl-- for decreasing font size and and Ctrl-+ for increasing font size. I want to prevent them. I figured out that they are bound to <body>, and I did:
document.body.addEventListener('keyup',
function(obj, e){e.preventDefault();}, false);
but it seems that in/decreasing font size is triggered before the event is sent to these handlers, and by the time preventDefault() is run, they are already done, and my attempt fails. How can I prevent these default bindings?
To (potential) downvoters: Read my question above carefully. I never wrote that I want to prevent zooming entirely. I want to unbind these functions from the particular key combinations that I mention. And if you think freeing Ctrl-- should not be done, then why does the Ace editor ships emacs keybinding with Ctrl-- bound to undo? Are you claiming that the developers of Ace editor (including Mozilla Firefox developers, among others) are doing something useless? Are you saying that you are superior than them? And even if your suggestion is not to do it, why downvote instead of writing that as an answer?
If you bind to the keydown event and you use e as the first argument, this code will work:
document.body.addEventListener('keydown', function(e) {
e.preventDefault();
}, false);
Demonstration
Note that this method does nothing to disable the browser's zoom feature, it just prevents the default behavior of all keyboard shortcuts. For example, you can still zoom with Ctrl+mouse wheel.
This one uses jQuery and checks to see if: the Ctrl key is pressed and the +/- buttons are pressed.
$(document).keydown(function(e) {
if(e.ctrlKey
&& (e.which == 107 || e.which == 109 || e.which == 187 || e.which == 189))
{
e.preventDefault();
return false;
}
});
I'm using this to disable the 'scrolling' effect the spacebar has in a browser. Will this affect other keypress events too?
window.onkeydown = function(e) {
return !(e.keyCode == 32);
};
Could someone please explain what this is doing? I'm not sure if this code is bad, but it seems to disable other keypress related codes in my page, and I want to make sure this isn't the reason.
Thanks!
ASCII code 32 is the ASCII value that represents the spacebar key, and your code is essentially telling the browser to return false whenever that keycode is detected. Since false is returned, the scrollbar effect you speak of is in fact successfully disabled.
However, the unfortunate side effect of this convenient spacebar-scroll-disabling function is that it disables spacebar keypresses everywhere on the page.
Instead of returning false, if the keycode is detected, pass the current scrollTop value into a closure that returns a function to a setTimeout event. When the setTimeout fires, the scrollTop position is reset back to the value it was in when the setTimeout event was first registered.
window.onkeydown = function(e) {
if(event.keyCode == 32) { // alert($(document).scrollTop() );
setTimeout(
(function(scrollval) {
return function() {
$(document).scrollTop(scrollval);
};
})( $(document).scrollTop() ), 0);
}
};
Your users can still conveniently make use of spacebars in input textboxes and textareas, and at the same time, pressing the spacebar key while not focused on a text element will no longer result in the page scrolling.
Under the hood, the scroll is still taking place. It's just being reset at a rate fast enough to where the user doesn't notice.
If you increase this value to 100 or 1000, it will give you a better idea of what is going on under the hood. You'll actually see the page scroll and then get set back to the previous scroll position.
This was only tested in Chrome and Firefox 13! So you may have to adjust the setTimeout duration -- currently 0 -- to a different value in browsers like Internet Explorer. Be prepared to gracefully degrade -- by supporting this feature only in modern browsers -- if necessary.
UPDATE:
For reference, below is the method to use to make this compatible in the major browsers. It has been tested in Chrome, Firefox, IE8, IE9, and Safari.
While it does work in IE8/IE9, it isn't very smooth.
// put the eventhandler in a named function so it can be easily assigned
// to other events.
function noScrollEvent(e) {
e = e || window.event;
if(e.keyCode == 32) {
setTimeout(
(function(scrollval) {
return function() {
$(document).scrollTop(scrollval);
};
})( $(document).scrollTop() ), 0);
}
}
// Chrome and Firefox must use onkeydown
window.onkeydown = noScrollEvent;
// Internet Explorer 8 and 9 and Safari must use onkeypress
window.document.onkeypress = noScrollEvent;
If another element is bound to the keydown event it will not be effected by this code
See my fiddle and try adding and remove the textarea listening to the keydown event
window.onkeydown = function(e) {
return !(e.keyCode == 32);
};
document.getElementsByTagName("textarea")[0].onkeydown = function(e) {
alert("hi");
}
http://jsfiddle.net/HnD4Y/
The answer above with the setTimeout did not work for me at all on Chome with a delay of 0. With a delay bumped above 50ms, it began to work, but that caused a noticeable page jump. I believe that setTimeout was scrolling the page up too early, then Chrome moved it down later.
Below is my solution that is working well. It returns false on the keydown event to prevent the browser from doing a page-down. Then you make sure event you set up on your button etc. to use the keyup event instead.
$(mySelector).keyup(eventHandlerFunction);
[dom element].onkeydown = function(event) {
if (event.keyCode == 32) {return false;}
};
Note: input fields will not reflect spacebar key events if they or their parent are covered by this onkeydown handler
I was playing with drag n drop in full forms (so no instant upload). I though small part was gonna be highlighting a certain fieldset when hovered over with a file. Enter dragover and dragenter events (and dragleave etc).
Turns out it's not such a small part. The Fiddle: http://jsfiddle.net/rudiedirkx/epp74/
Try it out: drag over a fieldset and move around a bit. The first over triggers the fieldset's dragenter event (fieldset is yellow). The moving around after that (within the same fieldset) triggers dragenters and dragleaves (fieldset no more yellow), which is bad.
Which is why I wanted to make what IE made for mouseover and mouseout a long time ago: mouseenter and mouseleave (they trigger just once). For drag events, the exact same thing applies: they should trigger only once in the exact same way. JS libraries spoof these IE events by using Event.fromElement and Event.toElement (and compare them against the event owner element). (See jQuery or Mootools source for specifics.)
To make the same for drag events, I need the same fromElement and toElement. You can see in the Fiddle, I try, but I can't find them.
Anybody know where they are? Why they're not available?
I'm using Chrome primarily, which doesn't have a fromElement in the dragenter event, but does have a toElement in the dragleave event. In Firefox it's slightly worse (but more logical): both are empty.
Any and all ideas are so very welcome.
edit
After a little more debugging I've found out that Chrome's toElement in dragleave isn't always correct. It's never 'bigger' thanthis, but sometimes it should be: when I leave the fieldset (this) to its parent form (toElement). When I do that, both this and toElement are the fieldset (which is incorrect, right?).
edit Solution:
I ended up with something like this: http://jsfiddle.net/rudiedirkx/Lwd3md71/ which ignores elements in the event, and uses the event coordinates to find the element under the mouse. To make it trigger max once per animation frame, it uses requestAnimationframe, which results into 31-59 fps.
Firefox provides the relatedTarget event property, but Chrome and Safari don't. Sadly, this issue has been open for a couple years as this Chrome bug and this Webkit bug.
Edit: The issue has been fixed in Chrome.
There is a way of faking the relatedTarget for a "dragleave" event, which is to set a variable from the accompanying "dragenter" event -- since dragleave is always preceded by dragenter, a variable set in the latter will be available to the former:
var relatedTarget = null;
document.addEventListener('dragenter', function(e)
{
relatedTarget = e.target;
}, false);
document.addEventListener('dragleave', function(e)
{
console.log('target = ' + e.target + ' relatedTarget = ' + relatedTarget);
}, false);
It won't work the other way round, but you don't really need dragenter for anything else if you use it this way -- i.e. the dragleave alone is enough to tell you when the mouse is moving into, or entirely out of, a particular element.