Is it possible to break on next event in IE10? - javascript

I'm working on a project that I haven't been with since the beginning so I don't know the code base very well yet. There seems to be an event on a textbox that runs on blur but I can't find it in the code at all. I'm hoping that IE has the debugger feature where it can break when a particular type of event has been triggered (in my case, the next blur to happen). Or is there a way to get a list of events on an input control?

You can pause script execution in Internet Explorer 10's Developer Tools. This will cause the execution to stop immediately just before the next script is ran. You can then step through execution to target the logic you're hunting for.
Alternatively, if you're binding events with jQuery you can tap into $._data and identify all of the bound events for any given element. For instance, suppose we had an input element that was behaving oddly, we could determine all bound events like this:
// We need a reference to the element, not a jQuery collection
var firstname = $("#firstname")[0];
// Next we pass the element as a reference
console.log( $._data( firstname ) );
This returns the full data object for that particular element. On this resulting object will be an events collection showing all events handled, as well as the handlers ran when those events are raised.
Hope this helps.

Related

Javascript Event Bubbling/Caputuring

Since every browser works different, whats the approach for a well working website?
I Mean i cannot know if I want attach it to bubbling or capturing phase since I don't know what the different Browser do first. And I don't want to write code for every browser. Corrent me if I'm wrong, but I read that every browser acts different.
So do I have to add a listener to every "child-widget" i have on the website and do stopPropagation() and cancelBubble = true; in every listener to have wanted behaviour for sure?
I Mean i cannot know if I want attach it to bubbling or capturing
phase since I don't know what the different Browser do first.
The behavior of events is fully defined in the DOM spec. The capture phase happens before the bubble one. See the following graphic from Event dispatch and DOM event flow:
Modern browsers are compliant.
Correct me if I'm wrong, but I read that every browser acts different.
Only old browsers behave unreliably.

Javascript execution in browser

This might sound silly, but has got me bugged for the past couple of days. I just wanted some clarity on how javascript is interpreted and executed in a browser, esp during event handling. Suppose i have two functions based on a click event for the same element. Might be two different event listeners written for two different classes, and the same element has both these classes during the click. Which function does the js executer run first?
Does the interpreter interpret the complete js file on event being triggered or use a bytecode generated during interpretation as in Java or specifically execute lines x - x+y?
Rather than knowing if function 1 would execute before function 2 or vice versa, i am more curious about the mechanism behind the whole process of registering and handling events using js.
i am more curious about the mechanism behind the whole process of
registering and handling events using js.
Think of it as a queue where events are getting pushed when you do element.addEventListener.
Queue has a property -> First-In-First-Out.
So, which ever event-listener has been added to the queue first (basically received by the event-target first) will be executed first, until all of them are executed.
Note: If the same event-handler method is added more than once (same parameters to addEventListener), then older one is replaced by new one.
Secondly, When we add the event via addEventListener we specify a boolean value called - useCapture. If the value is true, then events assigned to parent element is fired first and child-elements later, and vice-versa if this value is false.

Javascript: Atomicity / Interactions between browser view and DOM

I have two specific Javascript questions that are probably answered by one general answer. Please feel free to also submit the corresponding general question--I have difficulties expressing myself.
When I manipulate multiple DOM elements in a single Javascript callback, is the view possibly updated "live" with each individual manipulation, or atomically after the callback returns?
When a user clicks an HTML element twice in a short timeframe, and the corresponding click handler disables the HTML element, is there a guarantee that the handler won't be executed twice?
Preemptively, I do not have a standards citation for this. This is strictly in my experience.
I have never noticed the visible pixels update while Javascript is executing in real time. I suspect that they will not during the standard operation of the browser - it certainly is possible that debugging presents an exception. I have, however, observed synchronous reflow calculations occurring on DOM elements between the top and bottom of a single function call, but these reflow calculations never made it to the pixel buffer ( that I noticed ). These appear to occur synchronously.
function foo() {
$('#myElement').width(); // 100
$('#myElement').parent().width(); // 150
$('#myElement').css('width', 200);
$('#myElement').width(); // 200
$('#myElement').parent().width(); // 250
}
Regarding multiple clicks on an element that is disabled within the click handler, I suspect that the second click will not fire. I believe when the operating system receives a click event it passes it to the browser and it is placed in a queue. This queue is serviced by the same thread that executes Javascript. The OS click event will remain in the queue until Javascript completes execution at which time it will be removed, wrapped as a browser click event, and bubbled through the DOM. At this point the button will already be disabled and the click event will not activate it.
I'm guessing the pixel buffer is painted on-screen as another operation of this same thread though I may be mistaken.
This is based on my vague recollection of standards that I have seen quoted and referenced elsewhere. I don't have any links.
All script executions happen within the same thread. Therefore you can never have simultaneous actions and don't have to worry about concurrent modification of elements. This also means you don't need to worry about a click handler being fired while one is currently executed. However, this doesn't mean they cant immediately fire it again when your script is finished. The execution may be so fast that its indistinguishable.
First Bullet: The updates will be live. For example, attach the following function to an onclick handler:
function(){
var d = document.getElementById("myelement")
d.setAttribute("align", "center")
d.setAttribute("data-foo","bar")
d.setAttribute("data-bar","baz")
}
Now load this in your browser set a breakpoint on the first line. trigger the event and step through line-by-line while watching the DOM. The updates will happen live, they are not going to happen all at once.
If you want them to happen atomically, you'll want to clone the DOM element in question, make the changes on the clone, then replace the original element with the clone. The cloned element is still being updated in realtime, but the user-visible effect is atomic.
Second Bullet: If the second click event comes in after the element has been disabled, then yes, you won't get a second callback. But if there is any delay between the first click and the disable call, (for example some kind of lengthy check needs to be performed to determine if the element should be disabled) and the second click occurs in that delay, it will fire the callback a second time. The browser has no way to know that multiple click events isn't acceptable behavior in a given script.

document.write and delegated event handler persistence

I'm just testing out replacing a whole page with another page using JavaScript and I found this answer with document.write. As to why document.write, I needed to replace the entire HTML, including scripts and styles using the same page.
It does what I want but i can't seem to have consistency with my event handlers. My handlers are all attached to document using:
$(document).delegate(...);
Currently, I have weird results. In a fiddle I made, it attaches a handler. When clicked, the event fires, rewrites the page, runs the function again - but it doesn't attach the handler.
However in my project, I'm doing the same routine (d.w(), then add handlers). It does reattach once and handlers work, but after doing a second routine (still on the same page), it doesn't attach anymore.
So my questions are:
When using d.w(), do existing handlers get erased from document?
Are window as well as document the same after subsequent d.w()s? or are they somehow "renewed"
Do scripts that are already parsed stay in memory and run after subsequent d.w()s? Or do they get erased as well?
(The following applies to google chrome)
Only the document is cleared, the scripts in memory still stay the same. You can easily test it by setting something to a variable and see if it exists after clearing out the document with .open.
The old native handler is therefore lost from the document, but jQuery still thinks that the handler exists in its own event model. You can see it by editing the log to:
console.log('patch', JSON.stringify($.cache ));
jQuery only ever attaches a single native handler per event, so if you have a "click" event registered on document, further handlers attached with jQuery don't attach a new native handler, instead the handler is pushed into the jQuery internal handlers array.
Now, because document.open removed the native handler, but doesn't clear javascript, jQuery still thinks the native handler exists, and further .delegate only goes to the jQuery internal handler array. If you replace your handler with plain old document.onclick you will see it starts working.
You can also keep using jQuery if you add $(document).unbind() (or more robust $.cache = {};, but this is internal and subject to change) before the .delegate, so that jQuery is again synced. Otherwise it won't be, since it has no idea you called document.open.
So:
Yes
They are still the same objects, can be tested by saving a reference and checking that agaist document after a .open
They stay in memory.
http://jsfiddle.net/wphzt/4/
The only reason it stops working from second time onwards is because in your function you have written
document.write('<span>'+(++i)+'</span>');
In which case, next time the document doesn't have the delegate function to increment the span value but has only what you have written in the code snippet I have highlighted above. Thus, as you doubted, yes they get erased as well. Hope this helps.

order of events when a DOM element event is triggered

I have a Javascript function bound to the click event of an INPUT element (either checkbox or radio). That function examines the 'checked' property of the DOM element and takes action depending upon whether it is set or not.
If the user clicks on the element as represented in the GUI, the state of the checked property reflects the appearance in the GUI (that is, if the user's click activated the element, the checked property is true).
However, if I trigger the click event (using jQuery), then, when the bound-to-the-click function is invoked, examining the state of the checked property does NOT show the new state. However, the GUI does get updated to present proper representation of the actual state.
Is there a defined order to when these activities are performed? It seems odd to me that the event listener would be invoked before the checked property is set.
Interesting. The .click() called through jQuery has a different behaviour than calling .click() direct on the element. See here :
http://jsfiddle.net/g4aVm/6/
I would take this to indicate that jQuery is doing something non-standard/buggy here.
(I'm slight old fashioned and don't trust jQuery with simple DOM stuff. There's not much to gain by using a library to replicate what already exists, but that's a different discussion.)

Categories

Resources