doesn't show accurate line number at web browser

[atian25]

[TooTallNate]

You mean in the web browser?

[atian25]

yes

[TooTallNate]

Ya... I'm not sure if there's a way around this. We may be able to fix it in V8 using the stack trace API, but don't expect anything cross-browser.

[atian25]

well, I only care about Android WebView (2.2 ~ 4.4+)

[atian25]

I found angular.$log got the same problem, angular/angular.js#2975
is there any workaround like that ? bind

[TooTallNate]

I tried out the bind technique but the problem is that we do our own processing of the given arguments before calling the bound log function, so even still, it just points to the debug code rather than the user code that called the function.

I'm still pondering this but I'm not sure if there's a fix still...

[nicolashery]

Yes I noticed that too.

I've used bows before, and it seemed to show correct line numbers in the browser. I'm not sure what they are doing differently?

[manikantag]

@nicolashery Thanks for pointing to bows! It is logging correct line numbers. But I m not sure it's features complements 'debug.js' features, though.

[ProLoser]

The issue is that logs are deferred, do they really need to be? Can we just make deferring an optional argument flag?

[TooTallNate]

The issue is that logs are deferred, do they really need to be? Can we just make deferring an optional argument flag?

What makes you think that?

[ProLoser]

Isn't that what the stack traces shows? If I could just jump halfway up the stack trace and figure out where I called the log it would be fine. Or is it wrapped in a try catch? I don't remember, I created this issue #2975 over a year ago.

[TooTallNate]

It really just wraps the console.log call. It's not deferred using setTimeout or anything like that.

The problem is that the console will only display the call-site of the console.log() call, which always happens in the same place in debug, as opposed to the call-site of the debug() call, which is what we're actually interested in. Unfortunately I haven't come up with a solution for that.

[ProLoser]

@TooTallNate I meant they used to be deferred and executed in batch (like part of the $scope.$apply() stuff) This may have changed or I may have been confused from poking around the src code/stack trace, etc.

Can't we just move up the stack trace to see where the debug() was called? I mean if that worked it wouldn't be an issue, but from my recollection that just isn't the case.

[TooTallNate]

Ya AFAIK they've never been deferred.

Can't we just move up the stack trace to see where the debug() was called? I mean if that worked it wouldn't be an issue, but from my recollection that just isn't the case.

console.log() doesn't give you a trace though. You could switch to console.error() to get a trace, but then all the logs calls are red.