LibJS+Inspector: On the observability of console.log and Co
Note
This is regarding behavior not yet found in ladybird
As some stuff looks bugged or is maybe slightly out of sync with other browsers, or not implemented
There might be ways to essentially achieve the same as observed on other browsers, but I did not find them
console.log or similar may be done lazily by some browsers, for example firefox.
This leads to it being used as a sort of "debugger detection",
one way this was done is the past is using getters which were unconditionally executed,
but as modern browsers do not do so anymore, but offer a button to get them*
The modern iteration of that pattern is often leveraging toString functions of objects that implicitly call such functions when being printed,
such as Regexes. Function Objects and some DOM objects id fields might also work according to this SO answer on some browser versions.
Going forward it may be advisable to decide on how to handle these cases, especially as console.log prints directly to the debugging console on ladybird.
Here is an example script that directly sends you to "google.com" when you open the developer tools on firefox
<!DOCTYPE html>
<script>
a = /./;
a.toString = function () {
document.location = "https://www.google.com";
};
console.log(a);
</script>*: Turns out Error.message is unconditionally accessed on firefox, so from here:
console.log(Object.defineProperties(new Error, {
message: {get() {alert('Chrome/Firefox')}},
toString: {value() {(new Error).stack.includes('toString@')&&alert('Safari')}}
}));works fine for this purpose.
Ladybird seems to print
<already printed Object 0x00007f2ba1946040>
or similar, which is a clear lie/bug in its own right
How does funding with Polar work?
Pay now to fund the work behind this issue.
Get updates on progress being made.
Maintainer is rewarded once the issue is completed.
Backer
You're funding impactful open source efforts
Contributor
You want to contribute to this effort
Maintainer
You want to get funding like this too