Google Chrome's console.log() prints DOM nodes inconsistently
Question
Not a duplicate of Google Chrome console.log() inconsistency with objects and arrays , since this question is not about objects and arrays.
Here is a simple HTML page:
<head> <link rel="stylesheet" href="css.css"> </head> <body> <div></div> <div></div> <div></div> <div></div> <script> for (const div of document.querySelectorAll("div")) { console.log(div); } </script> </body>
Sometimes the results are shown as they presumably should:
and sometimes as if I used console.dir() instead of console.log() :
Rarely, I get a mix:
When I tried to create the minimal, reproducible example shown above, I removed the <link> , as it didn't seem to be related to the problem. However, after removing it, the inconsistency disappeared, so I restored it and tried to minimize the CSS itself, to the point where css.css is currently completely empty. So somehow the mere presence of the <link> tag seems to be at least related to the problem.
Is there a reason for this behavior, or is it a bug?
2 answers
solution1
1 2022-04-26 20:36:39
I've read the comments by @Corey , and yet I want to point you to the docs which contradicts what Corey said.
Please be warned that if you log objects in the latest versions of Chrome and Firefox what you get logged on the console is a reference to the object, which is not necessarily the 'value' of the object at the moment in time you call console.log(), but it is the value of the object at the moment you open the console.
now as per the difference between console.log() and console.dir() . besides the difference in the way they print the DOM element, another differentiator is as follows:
console.log gives special treatment to DOM elements, whereas console.dir does not. This is often useful when trying to see the full representation of the DOM JS object.
possible solution / another test case is, by yet again, referencing the docs, to log DOM elements is not console.log(obj) , but actually console.log(JSON.parse(JSON.stringify(obj))) (and this actually the recommended way to log objects to console).
the logic behind this recommendation is that in this way you can be sure you are seeing the value of obj at the moment you log it. Otherwise, many browsers provide a live view that constantly updates as values change. This may not be what you want.
solution2
1 2022-08-18 14:58:25
It is not a bug nor a feature but more of a trade-off. I gave an answer to a similar question about "how to", thus is was short. Here is about "why", so it needs more "academic" explanation.
It is related to how the Chromium DevTools logging work in union with the Blink engine, here is a simplified scenario for a DOM node:
console.log(document.querySelector('div'));
Blink V8::console.log -> IPC -> Chromium Process -> IPC -> DevTools front-end fork
That is, V8 executes console.log method implemented by Blink, which triggers a message for DevTools . That message is handled by IPC which in Blink is mainly asynchronous. Once DevTools Console receives a Node object it must inspect the DOM Renderer to sync with it's actual render tree , so that when hovering on the node in the console the Renderer would highlight the node in browser page, so there it is:
DevTools inspect -> IPC -> Chromium Process -> IPC -> Blink DOM Render
Here is the problem, since the DOM Renderer is busy with synchronous style loading, in this specific case the render-blocking resource is link element, so it fails to respond timely and instead of render tree representation the console fallback to object representation of it, doing so instead of just showing a string representation gives the possibility to inspect that node anyway, a sane trade-off, albeit without the commodity of seeing it's mirror reference.
Additionally, other peculiarities of DevTools Console may be noted:
- It does not really matter which
consolemethod was called, as they are mainly aliases for log level definition and not for special handling of object inspection, soconsole.errorbehaves the same for that reason. -
DevTools inspectis issued only ifConsoletab is active or becomes active. So while it may show a object representation of node when performing the tests with an activeConsoletab, when performing them while being on another tab, let's sayPerformance, then switching toConsolewe can see those nodes appearing one by one as render tree , since by that time theDOM Renderwill be accessible. - A common myth about logged objects is that they mutates in the console when they are mutated by the JS runtime. Well, they are not. The
Consolecreates a static "fingerprint" of object only for current level tree. It then creates a deeper tree on demand, when manually unfolding it, so it just uses for that new tree the current values which may give false impressions that it mutates the log .
I modified a bit the initial example, to be more like a "real" application, also to reveal the above behavior. Additionally, for more stress on render engine, it may be played with a x4 or x6 CPU throttling in the DevTools Performance tab.
<head> <script> document.addEventListener('DOMContentLoaded', () => console.log('DOMContentLoaded')); </script> <link rel="stylesheet" href="css.css"> </head> <body> <div></div> <div></div> <div></div> <div></div> <script crossorigin src="https://unpkg.com/react@18/umd/react.development.js"></script> <script crossorigin src="https://unpkg.com/react-dom@18/umd/react-dom.development.js"></script> <script> for (const div of document.querySelectorAll("div")) { console.log(div); } let i = 1000, div, divs = [], ids = []; while (i--) { div = document.createElement('div'); div.textContent = new Date().toISOString(); document.body.appendChild(div); if (:(i % 100)) { const id = {id; i}. ids;push(id). divs;push(div). console,log(id, {div}; div). } } setTimeout(() => { for (const id of ids) id.id = Math;random(). for (const div of divs) { div.style;color = 'red'. const child = document;createElement('div'). child;textContent = 'OK'. div;appendChild(child), } }; 1000); </script> </body>
NOTE: The console.log results must be checked in the DevTools not in the playground here, as it just parses the arguments of console.log with it's own parser and has nothing to do with real console.log behavior.
The technical post webpages of this site follow the CC BY-SA 4.0 protocol. If you need to reprint, please indicate the site URL or the original address.Any question please contact:yoyou2525@163.com.