I want to get the full DOM stack as a string. As an example, please open Chrome, press F12 and type "document.all". This object represents the full DOM. I want to convert this object as a string. In Chrome you're able to explore the object, expand sections and view their content in the web debugger console. Is there any possibility to convert document.all as a string? Or a similar solution with gives me the full DOM stack? I don't just want the innerHTML/outerHTML, I want the content of literally everything what's defined in the current DOM. Any ideas? Thanks in advance...
EDIT: Okay, I think my question is kind of confusing, sorry for that. To clarify this: I want to get every property of every object which is defined, including stuff like "document.location", "document.location.hash", "window.innerHeight", "document.body.innerHTML", and so on, by using JavaScript.
As far as I know, there's no way to get every property of every object.
In at least some browsers (Chrome, for instance), you can get most of the DOM with outerHTML on documentElement (the root element, e.g., html):
var html = document.documentElement.outerHTML;
You'd have to check whether your other target browsers do. At a minimum, they'll have innerHTML on body:
var bodyHTML = document.body.innerHTML;
But in terms of the other things, I don't believe there's any way to get every property of every object. For instance, you can find the properties on window like this:
var key;
for (key in window) {
// ...'key' is the property name, window[key] is the value...
}
...but that will only give you enumerable properties, not non-enumerable ones. And of course, you'd have to recurse into objects to get their properties (allowing for the fact that you can get to an object in more than one way — for example, window === window.window and there's also top, self, etc. to worry about; and similarly for document.all, document.forms, ...).
So unfortunately, while you can get a lot of the information you're talking about, I don't believe you can get it all.
You can implement this yourself using Object.getOwnPropertyNames, which will even include non-enumerable properties. I made a small example showing how this might be done.
Related
When I visit some page, like an SPA, I know some objects are added to window by its code.
Is there a way to know what are native browser objects/methods, and which were added by the app?
calling the window variable basicly give you an overview from all the content inside of it. I guess if you want to known how much functions it currently includes you could do something like:
Object.keys(window).length; //or just Object.keys for the names
To known if new functions have been added to the window object need to known the number of keys their where before they where included or just by knowning the static number. To just give some example. Here on stackoverflow the window object only contains 246 keys. However on something like google I counted 1597 keys. So it really depends on the app you are using.
So what you could do is write a function that checks if the amount of keys have been increased and when that happends taking out the key and moving it into a array inside the function.
That just what I get from your question.
I think you are looking for Mutation Observers. With them you can listen for newly added or removed DOM elements. I believe you also get notified of attribute and text changes.
Here is a link to a short article about them. Mutation Observers
Hope this helps!
Suppose you have two separate tabs. One that doesn't add anything to window (which is hard to find), one that have added some properties.
have both open.
in the clean one do :
a = Object.keys(window);
JSON.stringify(a);
copy the result and move that to the tab that have added some properties to window. then do a = JSON.parse(<Ctrl + v>)
and b = Object.keys(window)
and finally :
c = b.filter(p=>a.indexOf(p)=== -1)
now c contains names of all properties that have been added to window object by that tab;
HOT TIP:
Firefox Developer Edition does that by default :
a screenshot of how it works
Note that window's default properties are separated in a different property (called [default properties])
Today, I discovered something in Javascript that looked like "strange behavior" to me. Let's assume the following minimal example:
HTML:
<div id="test">
<span>1</span>
<span>2</span>
</div>
JS:
var div = document.getElementById('test');
var spans = div.getElementsByTagName('span');
div.removeChild(spans[0]);
div.removeChild(spans[1]);
(Fiddle: http://jsfiddle.net/SkYJg/)
Now, when running the script, I get an error:
TypeError: Argument 1 of Node.removeChild is not an object.
Looking closer, it turned out that spans[1] is null after the first one was removed. And indeed, the following code
var div = document.getElementById('test');
var spans = div.getElementsByTagName('span');
console.log(spans.length);
div.removeChild(spans[0]);
console.log(spans.length);
div.removeChild(spans[1]);
yields 2at the first log operation, but 1 the second time.
Now, it's pretty clear what happens here: after the first ?span? was removed from DOM, it's not part fo that HTMLCollection stored inside spans anymore either.
I always was under the impression, that the HTMLCollection-Object holds references to all objects that it contains. I didn't modify the collection anywhere after creating it. So I thought (but it was wrong, obviously) that the collection would behave like an array: references stay there until I delete/modify them manually.
I looked into the specification at MDN. And, indeed, richt at the top it says: HTMLCollections in the HTML DOM are live; they are automatically updated when the underlying document is changed.
The only way I could think of to prevent this is to loop over the collectino before doing anything with it, copying all references to an array, and use the array to access them afterwards. But that just looks so horribly bulky to me... is there a nicer solution? Like some way to make the collection static or to copy it without looping?
(in the minimal example I could just remove spans[0] twice, of course, but it isn't that simple in reality).
[Edit]: After seeing #Teemu's answer, I repeat: it's NOT that simple in my real code (that one is just too complex to show it here completely). I assure you, I really need random access to all elements that were inside that Collection, deleted or not.
A back-gate would be to use querySelectorAll() instead of getElementsByTagName(), it returns a non-live NodeList.
You're not using a "reference" when trying to remove the tag, just pointing the first or the second element of a collection. To use reference, you should create tags with ID and than point it by ID. The key of an Array is a third part, that's why it will be updated.
On the other hand, is a fact that JavaScript is objected-oriented sometimes, and other times it is just a script.
This question pertains as much to the ECMAScript language implementation we know as JavaScript as it does to jQuery and the developer tools availble in most popular browsers.
When you execute a statement like so:
var theElement = $('#theId').closest();
what is the type of theElement?
I assume that in a jQuery situation like above, many jQuery methods including the one above actually return the jQuery object itself, which packages the stuff you actually want to get to. This, so that it may maintain a fluent API and let you join method calls in a single statement like so:
$('#selector').foo().bar().gar().har();
However, in the case of jQuery then, how do you determine what the real underlying type is? For example, if the element returned was a table row with the Id tableRowNumber25, how do you get to that, say, using FireBug.
When I look at either a jQuery returned object or a simple JavaScript object in the watches window of Firebug or any of the Developer Tools in most popular browsers, I see a long laundry list of properties/keys and I don't know which one to look at. In a jQuery object, most of the properties are lamdas.
So, really, my question is -- how do you know the underlying type, how do you know what's actually being returned?
The type of theElement will be [object jQuery].
If you want the HTML element itself, you have to select it:
console.log(theElement[0]) //Return <div id='theId'>
console.log(theElement.get(0)) //Return <div id='theId'>
If you want the node name, there is a property in the HTML node element call nodeName wich return the capitalised node name:
console.log(theElement[0].nodeName)// Return DIV
typeof(jQueryElementList.get(0)) will return a string of the type.
Some browsers might return this as upper or lower case, I think. IE probably uppercases (see Testing the type of a DOM element in JavaScript). Apparently you can check the nodeType attribute (jQueryElementList.get(0).nodeType) to determine whether it is an html object/tag.
I'm having a strange issue in IE8 where I'm trying to grab something by simply doing:
window.frames.frames[0].name; // get the name of the inner iFrame object
Nothing fancy, but when script is ran, IE7-8 interpret it like this:
window.frames.frames.0.name;
// which in-turn gives the error
// 'window.frames.frames.0.name' is null or not an object (which is not true)
Why and how is it converting this, and why isn't it even working anymore??
If I type the first one window.frames.frames[0].name; into the console of IE8, it grabs the correct iFrame. But typing in what IE8 interprets (window.frames.frames.0.name;), doesn't work at all... (strangely says, "Expected ';'", which makes zero sense haha.
Anyone ever run into an issue like this?
That dot notation in the error message is just a string the browser uses, poor choice on the browser developers.
The line `window.frames.frames[0].name` does not make sense.
I would expect
window.frames[0].name
or if it is nested frame in a frame
window.frames[0].frames[0].name
window.frames is an array, is it not? Shouldn't you be indexing the first frame?
window.frames[0].frames[0].name;
Does it work if you put parentheses around the the call? like this:
(window.frames.frames[0]).name; // get the name of the inner iFrame object
Also do you really mean do reference window.frames.frames[0] and not just window.frames[0]?
Or do you mean:
window.frames[0].frames[0].name; // get the name of the inner iFrame object
Let's say that we have a DIV x on the page and we want to duplicate ("copy-paste") the contents of that DIV into another DIV y. We could do this like so:
y.innerHTML = x.innerHTML;
or with jQuery:
$(y).html( $(x).html() );
However, it appears that this method is not a good idea, and that it should be avoided.
(1) Why should this method be avoided?
(2) How should this be done instead?
Update:
For the sake of this question let's assume that there are no elements with ID's inside the DIV x.
(Sorry I forgot to cover this case in my original question.)
Conclusion:
I have posted my own answer to this question below (as I originally intended). Now, I also planed to accept my own answer :P, but lonesomeday's answer is so amazing that I have to accept it instead.
This method of "copying" HTML elements from one place to another is the result of a misapprehension of what a browser does. Browsers don't keep an HTML document in memory somewhere and repeatedly modify the HTML based on commands from JavaScript.
When a browser first loads a page, it parses the HTML document and turns it into a DOM structure. This is a relationship of objects following a W3C standard (well, mostly...). The original HTML is from then on completely redundant. The browser doesn't care what the original HTML structure was; its understanding of the web page is the DOM structure that was created from it. If your HTML markup was incorrect/invalid, it will be corrected in some way by the web browser; the DOM structure will not contain the invalid code in any way.
Basically, HTML should be treated as a way of serialising a DOM structure to be passed over the internet or stored in a file locally.
It should not, therefore, be used for modifying an existing web page. The DOM (Document Object Model) has a system for changing the content of a page. This is based on the relationship of nodes, not on the HTML serialisation. So when you add an li to a ul, you have these two options (assuming ul is the list element):
// option 1: innerHTML
ul.innerHTML += '<li>foobar</li>';
// option 2: DOM manipulation
var li = document.createElement('li');
li.appendChild(document.createTextNode('foobar'));
ul.appendChild(li);
Now, the first option looks a lot simpler, but this is only because the browser has abstracted a lot away for you: internally, the browser has to convert the element's children to a string, then append some content, then convert the string back to a DOM structure. The second option corresponds to the browser's native understanding of what's going on.
The second major consideration is to think about the limitations of HTML. When you think about a webpage, not everything relevant to the element can be serialised to HTML. For instance, event handlers bound with x.onclick = function(); or x.addEventListener(...) won't be replicated in innerHTML, so they won't be copied across. So the new elements in y won't have the event listeners. This probably isn't what you want.
So the way around this is to work with the native DOM methods:
for (var i = 0; i < x.childNodes.length; i++) {
y.appendChild(x.childNodes[i].cloneNode(true));
}
Reading the MDN documentation will probably help to understand this way of doing things:
appendChild
cloneNode
childNodes
Now the problem with this (as with option 2 in the code example above) is that it is very verbose, far longer than the innerHTML option would be. This is when you appreciate having a JavaScript library that does this kind of thing for you. For example, in jQuery:
$('#y').html($('#x').clone(true, true).contents());
This is a lot more explicit about what you want to happen. As well as having various performance benefits and preserving event handlers, for example, it also helps you to understand what your code is doing. This is good for your soul as a JavaScript programmer and makes bizarre errors significantly less likely!
You can duplicate IDs which need to be unique.
jQuery's clone method call like, $(element).clone(true); will clone data and event listeners, but ID's will still also be cloned. So to avoid duplicate IDs, don't use IDs for items that need to be cloned.
It should be avoided because then you lose any handlers that may have been on that
DOM element.
You can try to get around that by appending clones of the DOM elements instead of completely overwriting them.
First, let's define the task that has to be accomplished here:
All child nodes of DIV x have to be "copied" (together with all its descendants = deep copy) and "pasted" into the DIV y. If any of the descendants of x has one or more event handlers bound to it, we would presumably want those handlers to continue working on the copies (once they have been placed inside y).
Now, this is not a trivial task. Luckily, the jQuery library (and all the other popular libraries as well I assume) offers a convenient method to accomplish this task: .clone(). Using this method, the solution could be written like so:
$( x ).contents().clone( true ).appendTo( y );
The above solution is the answer to question (2). Now, let's tackle question (1):
This
y.innerHTML = x.innerHTML;
is not just a bad idea - it's an awful one. Let me explain...
The above statement can be broken down into two steps.
The expression x.innerHTML is evaluated,
That return value of that expression (which is a string) is assigned to y.innerHTML.
The nodes that we want to copy (the child nodes of x) are DOM nodes. They are objects that exist in the browser's memory. When evaluating x.innerHTML, the browser serializes (stringifies) those DOM nodes into a string (HTML source code string).
Now, if we needed such a string (to store it in a database, for instance), then this serialization would be understandable. However, we do not need such a string (at least not as an end-product).
In step 2, we are assigning this string to y.innerHTML. The browser evaluates this by parsing the string which results in a set of DOM nodes which are then inserted into DIV y (as child nodes).
So, to sum up:
Child nodes of x --> stringifying --> HTML source code string --> parsing --> Nodes (copies)
So, what's the problem with this approach? Well, DOM nodes may contain properties and functionality which cannot and therefore won't be serialized. The most important such functionality are event handlers that are bound to descendants of x - the copies of those elements won't have any event handlers bound to them. The handlers got lost in the process.
An interesting analogy can be made here:
Digital signal --> D/A conversion --> Analog signal --> A/D conversion --> Digital signal
As you probably know, the resulting digital signal is not an exact copy of the original digital signal - some information got lost in the process.
I hope you understand now why y.innerHTML = x.innerHTML should be avoided.
I wouldn't do it simply because you're asking the browser to re-parse HTML markup that has already been parsed.
I'd be more inclined to use the native cloneNode(true) to duplicate the existing DOM elements.
var node, i=0;
while( node = x.childNodes[ i++ ] ) {
y.appendChild( node.cloneNode( true ) );
}
Well it really depends. There is a possibility of creating duplicate elements with the same ID, which is never a good thing.
jQuery also has methods that can do this for you.