Welcome to Code Forum!

Join a community that supports you and your coding journey from day one. We strive to be a friendly, supportive community that empowers everyone to be better developers. By registering with us, you'll be able to discuss, share and private message with other members of our community.

SignUp Now!
  • Guest, before posting your code please take these rules into consideration:
    • It is required to use our BBCode feature to display your code. While within the editor click < / > or >_ and place your code within the BB Code prompt. This helps others with finding a solution by making it easier to read and easier to copy.
    • You can also use markdown to share your code. When using markdown your code will be automatically converted to BBCode. For help with markdown check out the markdown guide.
    • Don't share a wall of code. All we want is the problem area, the code related to your issue.

    GIF shows where to locate </> in the thread and or post editor toolbar.
    To learn more about how to use our BBCode feature, review our "How to post your code into threads" here.

    Thank you, Code Forum.

JavaScript console.log redirection works once, but subsequent attempts fail

j1fcZKmy

New Coder
I am overwriting console.log so that I can observe an event and take action on it.

This is done via go, when I launch a new tab by clicking a link, so it happens quickly.

JavaScript:
window.originalLog = console.log;
window.capturedLogs = [];
console.log = (...args) => {
window.capturedLogs.push(...args);
originalLog(...args);

When I observe that event, I take an action and then I'm good. Now, the problem comes into play when I close that tab and repeat the process (open a new tab). The problem is that it always fails after the initial attempt and always succeeds on the first attempt (new browser session).

AFAIK, window variable refers to the current tab and not the entire browser "window". I understand this could be related to timing and the only thing I can surmise is that possibly it is quicker to attach to the window the first time than subsequent times and the specific event is missed.

Whenever I look at window.capturedLogs, the size is substantially smaller for later attempts which is strange.

1. What would cause this to fail after the initial attempt?
2. Are there any alternatives to this approach that would be more reliable? I am not a JavaScript developer - I primarily do Java, so this was the first thing that worked that I stumbled upon ...
 
Last edited:
I don't think it has to do with the logs becoming too large and perhaps rolling over as I tried rewriting the above to update a boolean flag to true when matched and the same thing happens, it only gets set to true for the first iteration.

I see the same log message in latter instances.
 
Without sharing the specific logs, the pattern I observe is this:

1. messages without a timestamp in them are captured in both cases
2. messages with the timestamp are not captured in subsequent cases, but the interesting thing is, they're still written to console.log. I kept the original target and write to that as well, so the logs are identical. I wonder if somehow the messages are being dropped because they're being seen as a different type the second go-round?
 
Without sharing the specific logs, the pattern I observe is this:

1. messages without a timestamp in them are captured in both cases
2. messages with the timestamp are not captured in subsequent cases, but the interesting thing is, they're still written to console.log. I kept the original target and write to that as well, so the logs are identical. I wonder if somehow the messages are being dropped because they're being seen as a different type the second go-round?

It seems like the reason logs with timestamps “disappear” is that another script (or the browser itself) is re-wrapping console.log after your code runs, so your saved originalLog isn’t the function that actually gets called anymore. You can fix this by binding the original (window.originalLog = console.log.bind(console)) so it always has the right context, and by guarding against double-wrapping with a simple flag. If you need it bullet-proof, you can either lock the method with Object.defineProperty or use a Proxy around console so even if other code overwrites it later, your capture still fires.
 
Yes - I found a way around it, it actually declares a logger object for which I can directly fetch an array and then inspect the contents for what I want ...

I think this bit if trickery I was doing above is fragile and should be avoided if possible.
 

Latest posts

Buy us a coffee!

Buy me a coffee.
Back
Top Bottom