Hacker News Reader

Comment by adamnemecek | Hacker News Reader

Haha, I agree.

They do seem to have some strange restrictions on this. E.g. When you evaluate it the function returns undefined but it also outputs the array underneath. You can right click and save it to variable.

I think the point of this so that you cannot assign the output programmatically, there has to be a person who saves it to a variable by right clicking.

View on HN

I think it’ll be because for architectural reasons it can’t return a value synchronously, combined with historical ergonomic reasons. I don’t know when it was introduced, it’s possible that originally it could be synchronous and only subsequent V8 changes prevented that. Probably it landed before you could use `await` in the console, and they decided that made the ergonomics of Promising it too bad for the typical use case (though now you could write `await queryObjects(Function)` if it worked that way). All I know is that the documentation at https://developer.chrome.com/docs/devtools/console/utilities... says it returns an array of objects, which is patently false.

I can’t see any reason for preventing assigning the output programmatically.

I work on Chrome DevTools.

The reason is absolutely security concerns. You don't want to leak a function that can expose a list of all objects on the JS heap.

I don’t understand. The page can’t access these things, only dev tools, so any action to expose it would still have to be mediated by user action; and even then, what’s so bad about exposing this? Everything in it is scoped to the document, and if it can expose things you don’t want exposed, then so can getEventListeners(), right? Yet getEventListeners returns an actual value. What’s the actual security problem of being able to list all objects on the JS heap?

Reply on news.ycombinator.com