Does document reload every time DOM changes via Javascript? - javascript

I kind of have a newbie question. I've done some testing, but I didn't get anything solid, so does the whole document reload when DOM is updated?

No, the document is not reloaded when the DOM is updated.
You can test it using this example: http://jsfiddle.net/AATC6/
There is an alert in the load event for the page, and you can click on the link to add an element to the DOM, which does not cause the load event to be triggered.

No it does not. However there is an event for some browsers DOMSubtreeModified which can be used to track changes to the DOM.

Related

History back bug in turbolinks to a page with hash

I'm having a little annoying problem with Turbolinks in rails, which I hope some of you can help me with.
I'm using jQuery-address to add hashes to my url in order to execute some javascript, when a specific hash value occurs.
The problem is that Turbolinks doesn't seem to work, if I click the back button (history back) and the history back refers to an URL with a hash. It simply doesn't change the page content. E.g. mypage.com/test2 and i go back to mypage.com/test1#1.
I want to make a js fix, so if I hit another page with a hash using history back, it should reload the page to refresh the content OR just force the content to refresh manually with Turbolinks.
Thanks in advance!
The best information I can give without code is that Turbolinks refreshes the <body> of the page
Delegation
Normal HTML rendering is to re-render the entire page, meaning your JS is able to re-bind to the different elements. The way JS works is to bind an event to a specific element. That element has to be on the page (document / DOM) itself in order for the JS to bind to it.
Turbolinks is notorious for preventing JS from binding events to elements. As Turbolinks keeps the same JS on the page, it prevents binding for the JS. Instead, you'll need to use the turbolinks event handlers to bind your events to the DOM, and delegate through turbolinks, like so:
var ready = function(){
//your code here
};
$(document).on("page:load ready", ready);

Prevent Firebug from Removing HTML Elements

I'm sure we've all done it by now. A website pops up some goofy JavaScript modal preventing you from continuing. You whip out Firebug, inspect it, and hit Delete. Poof! Gone. Now, is there a way with JavaScript to recreate the element or disable that functionality altogether? Thanks!
Create a js reference to the element on page load. Add a listener to the element that looks for the destroy event. If that happens, then use your reference to recreate the item. The only issue is firebug might not fire a destroy event when an element is manually deleted. In that case, you could have a loop that checks every x milliseconds to see if the element is there. If it isn't, then create a new one.

Detect JavaScript initiated change on a JavaScript created object

I have a TEXTAREA that is created through an external JavaScript. I am writing new script to detect when the contents are changed. DOM events like "change" and "blur" do not work, since the change is initiated by the other script. I do not have the ability to read/modify the external script.
Any ideas?
If you want full cross-browser support, you will simply have to set up a polling interval and compare the contents each time to what you saw the last time. DOM mutation events aren't going to cut it.
Have fun.

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.

jquery lost events

I would like to know if is there some jquery known behaviour that cause the lost of events handlers (in particular in iframes)?
I've a strange kind of problem.
I've built a webapp composed of two iframe.
First i load content in the first iframe. I add some event event handler using jquery to first iframe content dom.
Everything works.
On user input i load a page in the second iframe. Here too, I add some event handlers using jquery.
Then the strange thing happens: jquery lost the event handlers in the first iframe.
I said 'jquery lost' because if I add an event listener old way, it is still present.
Problem solved.
The problem was caused accessing iframe2.contentWindow or iframe2.contentDocument on the second iframe, when the src of the second iframe was changed (1st time everything worked, from the 2nd onward caused problems) and the second frame was statically coded in the html.
To solve the problem I always remove the second iframe and recreate and append it to dom dynamically via javascript.
The problem occurs only on opera 9.7 embedded for mips (not sure for the exact version)
You might want to use live to bind events. This way when you add new elements with the same selector it will have the event binded to them.
$("p").live("click", function(){
$(this).after("<p>Another paragraph!</p>");
});
Every subsequent p that is added to the page will have the event binded too.

Categories

Resources