I've just discovered that both window.fireEvent and window.dispatchEvent are undefined in IE8, however document.fireEvent exists.
So how on earth do I trigger events for the window element in IE8?...
It's impossible. The way jQuery etc does this is by virtually emitting events within jQuery, rather than using the native event emitting.
Related
I have a simple countUp/Down utility, which utilizes requestAnimationFrame to set the textContent of a specific DOM. Surprisingly every time I make the content update, the browser triggers a reflow. Is there any way to avoid this?
There is a simple demo on requestAnimationFrame found in CodePen, using the performance tool of Chrome dev tool, you can see each callback call is followed by reflow (Layout)
To my knowledge, setting textContent shouldn't cause style recalculation. I have also tried giving the element fixed dimension, but that did not help.
Unlike some methods, it doesn't trigger a reflow synchronously, but when the next painting will occur, the browser will still have to recalculate the layout since the textContent change could have changed the page's layout.
The only way to avoid a reflow at all I can think of, would be to render this text in a <canvas>.
I am trying to drag an element and drop to another element on the page. My code runs without any errors. But the drag actually doesn't happen.
It's able to find both the elements. I tried all the options listed below:
driver.browser.action.drag_and_drop(fromobject.native,
toobject.native).perform
fromobject.drag_to toobject
driver.browser.action.move_to(toobject.native).release.perform
fromobject.drag_and_drop_on toobject
If from_element.drag_to to_element doesn't work for you, then it's probably not going to be possible to do it directly with capybara/selenium. The reason for this is that drag and drop support in drivers is highly dependent on what events your code is looking for. Current versions of selenium implement it as the events mouse down, mouse move, mouse up whereas your code may be looking for drag start, drag, drag end events, etc. Because of this, to make it work you'll need to create synthetic events using execute_script to trigger the behavior you want. If you are using specific libraries someone may have already implemented this nicely for you - for instance, if you're using JQuery UI Sortable elements there is https://github.com/mattheworiordan/jquery.simulate.drag-sortable.js
I need to find the previously focused item in my focusin function. Here is an example code:
$('#id').on('focusin', function(event) {
//console.log(event.relatedTarget.nodeName); //doesn't work
}
I've done some research and while I've seen some people saying in posts that this only works with mouse events like mousedown etc., I've come across a few articles from reputable sources that have me believing this should work.
https://developer.mozilla.org/en-US/docs/DOM/event.relatedTarget Here Firefox specifically mentions how event.relatedTarget returns "which EventTarget is losing focus" in the 'focusin' event.
Firefox is the browser I am using for this.
http://www.w3.org/TR/DOM-Level-3-Events/#events-FocusEvent at this bookmark you can see that every FocusEvent has a readonly attribute called related target.
http://www.w3.org/TR/DOM-Level-3-Events/#event-type-focusIn Here they specifically state as well that the 'FocusEvent' has a property called 'relatedTarget' which is "event target losing focus (if any)."
So then what am I doing wrong here? It must be some kind of dumb syntax mistake or something. I cannot find the nodeName of event.relatedTarget.
Update: I can get it to work in IE using, but this won't work in Firefox???
$("#id").on('focusin', function(event) {
$('#textbox').text(event.relatedTarget.nodeName);
}
Although MDN mentions relatedTarget for the focusin /focusout events, unfortunately, no version of FireFox actually supports those two events. jQuery simply emulates them for you but due to lack of native support, you don't get relatedTarget on FF.
See compatibility info here or here.
I've got this in my html file:
<textarea id="inputbox" placeholder="type here"></textarea>
What's the correct way to wire up a handler that will fire immediately whenever the content of the textarea changes? (whether by keyboard, mouse/clipboard, speech input, brainwave reader, etc)
I tried:
query("#inputbox").on.change.add(handler)
but (at least on Dartium) it only fires after you tab out of the field.
The purpose is to update a "live preview" window, similar to the way Stackoverflow renders Markdown output while you type.
This is the best I came up with so far. I'd be happy to hear if anyone knows of a more compact or preferable alternative.
Edit: Code snippet updated to the new pattern for event registration.
import 'dart:html';
void main() {
query("#inputbox")
..onChange.listen(handler)
..onKeyDown.listen(handler)
..onKeyUp.listen(handler)
..onCut.listen(handler)
..onPaste.listen(handler);
}
void handler(Event event) {
print((query("#inputbox") as TextAreaElement).value);
}
The precise behavior will vary between browsers and operating systems.
You could skip keyDown, but be aware keyDown and keyUp behavior is influenced by the OS and isn't guaranteed to be symmetric. You might conceivably miss a change, at least until the next keyUp or change event gets fired. Indeed I proved this out by creating a little app on Windows 7 to send an orphan WM_KEYDOWN message to Dartium and IE9.
keyPress could be used instead of keyUp and keyDown, but won't generate events for certain keys like backspace and delete.
cut and paste react immediately to a cut or paste performed with the mouse. If you don't use them, the change event will capture the change, but not until after the field loses focus, or sometimes even later.
The input event could replace all listeners above and seems to work great in Dartium, but under IE9 it only captures character additions, not removals.
Note keyUp and keyDown may generate additional unwanted events for cursor keys, home, end, shift, etc. (e.g. In IE9). It will fire in addition to the cut/paste listeners when the user uses shortcut keys for those actions.
While the question is specific to Dart, a lot of the discussion above applies to any code listening to the DOM. Even keyCode values aren't standardized across browsers (more detail).
It may also be worthwhile checking out the KeyboardEventController class, though by and large when I tested it the edge case behavior was similar to that noted above. That may or may not be by design. The Dart developers do make some effort to insulate you from cross-browser inconsistencies, but it's still a work in progress.
Also while we're talking about textarea, remember to use its value property, not its text property. Finally, be sure your handler throttles its reactions to "bursts" of keyboard activity (e.g. some sort of timer that briefly defers the guts of your handler and rolls up any additional events which occur in the meantime).
Related questions and links:
Handle events in DART
Handling Keyboard events in Dart Language
How do you listen for a keyUp event in Dart?
Cross browser key event handler in Dart
jQuery example that skips keyboard events and binds to propertychange
Its not clear if you are using polymer or not, but if you are, you can subscribe to a change to a variable annotated with #observable by creating a function in the polymer element in the form as [variable name]Changed(oldvalue). I originally found this here: How to subscribe to change of an observable field
I have an image element, following is the html for the button
<input type="image"src="images/undo.png" onmouseover="this.src='images/undo-hover.png'" onmouseout="this.src='images/undo.png'" id="btn_back" onClick="back();" >
When my application makes this input disabled (attribute disabled="disabled") all browsers stop firing mouse events. So I don't get hover images. But opera still keeps firing these event, and I keep getting the hover images on disabled elements.
Can you please try making the INPUT element disabled by default (add disabled="disabled" in the INPUT tag from start). Then see if Opera is still responding to mouse hover. This may not fix the issue right away but will help in figuring out the cause.
Also, another approach could be to call the JS function on mouse event and check if the element is disabled or not. If it is disabled then dont change the src attribute.
HTH,
this is a bug in Opera as we're apparently doing something different than other browsers. Please report it on https://bugs.opera.com/wizard/ and give me the bug ID.
That said, I don't think what you are relying on is standardised anywhere, so possibly you should not write code that depends on this somewhat quirky behaviour. The "disabled" attribute merely means that the element will not do its normal action when clicked. I don't really see any reason why setting disabled should prevent firing mouseover/move. It's easy to check from JS if the button is disabled and not swap the image if it is.
It seems like an expected behavior in opera, Please see the following link.
http://www.quirksmode.org/dom/events/click.html
It says that "A click event on a disabled form field does not fire events in Firefox and Safari. Opera fires the mousedown and mouseup events, but not the click event. IE fires mousedown and mouseup, but not click, on the form. All these implementations are considered correct."
Thanks,
Unnikrishnan B.