When you click on a source file link in the JS Console, it should scroll down to the line that the problem happened on. I'm assuming that bug 15364 (add line numbers to view source) will take care of adding line numbers to windows that these links pop up; if not, I'll file a separate bug for that.

JSDebugger != JS console. hewitt: do you want to add this to your other enhancement requests?

This would be neat, but first, view source would have to support the ability to scroll directly a specific line in the source.

*** Bug 92121 has been marked as a duplicate of this bug. ***

This works. It's a little rough around the edges and needs performance testing, so far...

ccing some interested parties. Doron, Harish, what do you think of this approach? Perf testing is not promising so far -- I'm seeing a 20% speed hit. :(

To be specific: 1) http://www.toronto.com -- largish page, all on one line. No speed hit 2) http://www.cnn.com -- largish page, many lines. About 15% speed hit. 3) http://www.w3.org/TR/2001/WD-DOM-Level-2-HTML-20011210/html.html -- lots and lots of lines. About 25% speed hit. pretty much all the speed hit comes from the actual creation of the <a> nodes and their insertion into the source... Doron, is this worth working on? Or will your scrollByLines patch see the light of day sometime?

My scrollbylines is done, just, I have no tree at the moment :) A better approach is for the javascript in viewsource.js to check for a # in the uri. We could first check for a anchor with that name and scroll to it. If there is none, and there is a number after #, then we scroll to it (using window.scrollto()). As for the anchor checking, might cause some perf issue (looking at all <a> tages with the name attribute foo).

Well, the advantage of the scrollbylines solution is that it does not incur the perf hit associated with the insertion of all those <a> tags into the source... So if it works and works well (we should test how it handles fonts of various sizes, just in case, eg if the user styles comments with a different font size from the other view-source stuff) then we should use it.

So, do we want to give the line number in the url or via window.arguments?

I say we do it via window.arguments. Then the viewsource code is free to put it in the url or just use scrollbylines, or whatever. The patch in this bug was just sorta hacked together for demonstration purposes. :)

*** Bug 145027 has been marked as a duplicate of this bug. ***

I have this working kinda, it just breaks when you have wrap long lines on

Fixed by patch in bug 104383 (combination of some line numbers in the back end and some clever JS in the front end). Many thanks to Christian for the patch!

I don't seem to work for me (build 2003052508) The issue is that the source file usually contains comments, which is good, but the Javascript parser probably ignores them (and that's it job, isn't it) and then the line number known from the javascript parser is shifted and doesn't match with the line number in the real source file Example: Error: redeclaration of const MOZ_HELP_URI Source File: chrome://help/content/contextHelp.js Line: 1 goes to /* -*- Mode: Java; tab-width: 2; indent-tabs-mode: nil; c-basic-offset: 2 -*- while it should go to const MOZ_HELP_URI = "chrome://help/content/help.xul"; which is line 21 I agree that this enhancement is a good idea, however it doesn't get the right info to work properly (the target line number is inaccurate)

that's a problem w/ the xul content sink, i'm sure there's a bug for it, but it isn't this bug.

Actaully, that's just a bug with the JS engine's line number reporting, since the error is clearly not in line 1. It may only come up in fastloaded scripts, since I think we do handle comments in the normal case. But in any case, please file a bug on the JS engine to report a line number that has bearing on reality.

report created for misleading line number info http://bugzilla.mozilla.org/show_bug.cgi?id=208030

bz: The JS engine does keep track of lines properly, as far as I know, as as I designed and implemented long ago, with help from jband's early debugger work to shake out ugly edge cases. I look forward to a testcase showing otherwise, over in bug 208030. /be