Line numbers in nested document.write()s
Henri Sivonen
parser when there are nested document.written scripts. See Error Console
with
http://hsivonen.iki.fi/test/moz/line-numbers.html
Does Firebug or anything else rely on a particular way of counting lines
in nested document.write()s? If yes, what's the expectation?
--
Henri Sivonen
hsiv...@iki.fi
http://hsivonen.iki.fi/
Boris Zbarsky
> I don't see much logic in the line number reporting of the old HTML
> parser when there are nested document.written scripts. See Error Console
> with
> http://hsivonen.iki.fi/test/moz/line-numbers.html
Looks good to me: the line number listed is the line number in view
source where the relevant throw shows up, no?
-Boris
John J. Barton
> I don't see much logic in the line number reporting of the old HTML
> parser when there are nested document.written scripts. See Error Console
> with
> http://hsivonen.iki.fi/test/moz/line-numbers.html
With Firebug installed, my Error Console if FF 3.5 and 3.6b1 shows one
nonsense warning:
Warning: Non-standard document.all property was used. Use W3C standard
document.getElementById() instead.
Source File: http://hsivonen.iki.fi/test/moz/line-numbers.html
Line: 3
The line number for the warning is wrong.
In addition, I see two calls to jsd.onError:
uncaught exception:
2147500033@file:///C:/mozilla/firefox-3.6b1pre.en-US.win32/firefox/modules/utils.js:1058.0
Stack
Exception is not defined in
http://hsivonen.iki.fi/test/moz/line-numbers.html
line 5
These two errors do not show up in the Error Console.
Firebug classifies the document.write buffers as 'events', which is
probably wrong.
>
> Does Firebug or anything else rely on a particular way of counting lines
> in nested document.write()s? If yes, what's the expectation?
My expectation is that the line numbers from error messages will be
wrong. Firebug tries to fix some of these cases, but for the most part
the only time line numbers on errors are correct is in .js files.
jjb
Henri Sivonen
Boris Zbarsky <bzba...@mit.edu> wrote:
If that were the logic, then the warning for document.all doesn't follow
that logic in the demo.
Henri Sivonen
"John J. Barton" <johnj...@johnjbarton.com> wrote:
> My expectation is that the line numbers from error messages will be
> wrong. Firebug tries to fix some of these cases, but for the most part
> the only time line numbers on errors are correct is in .js files.
Thanks. I take this to mean that I have some liberty in how I make the
HTML5 parser count lines in document.written content.
Boris Zbarsky
> If that were the logic, then the warning for document.all doesn't follow
> that logic in the demo.
Yes, I think that warning is buggy.
-Boris
Boris Zbarsky
>> My expectation is that the line numbers from error messages will be
>> wrong. Firebug tries to fix some of these cases, but for the most part
>> the only time line numbers on errors are correct is in .js files.
>
> Thanks. I take this to mean that I have some liberty in how I make the
> HTML5 parser count lines in document.written content.
It needs to count them in such a way that the links in the error console
work correctly, ideally.
-Boris
John J. Barton
Boris, I don't think Henri can succeed. This is essentially the same
problems 'eval()': these new source lines are not in the "source", so
any line number relative to the "source" will be incorrect.
I think for all these dynamic cases we need a new approach. Each
compilation unit needs to be cached, assigned a unique identifier, and
chained to the compilation unit that injected the code. This is what
Firebug does for eval(), but can't do for 'new Function()' and should do
for 'document.write()'.
jjb
Henri Sivonen
Boris Zbarsky <bzba...@mit.edu> wrote:
This can't be done with the current script infrastructure.
document.write() doesn't report to the parser what line it was on in the
script. Also, the line numbers for inline scripts will be wrong when
line breaks in an inline script have been escaped as numeric character
references, since the JS parser will count those as line breaks but they
aren't line breaks in the source.
Henri Sivonen
Henri Sivonen <hsiv...@iki.fi> wrote:
> This can't be done with the current script infrastructure.
> document.write() doesn't report to the parser what line it was on in the
> script.
Maybe it would be better not to report the line number at all when the
parser knows it can't produce a non-bogus line number?
Boris Zbarsky
> Maybe it would be better not to report the line number at all when the
> parser knows it can't produce a non-bogus line number?
This is an option, but a line number that's a few lines off is slightly
more useful than no line number at all, imo....
-Boris
Mark Tyndall
If the parser knows it's wrong, it could generate "near line 436" or
whatever...
Mark..
Henri Sivonen
Mark Tyndall <moz_...@tyndall.org.invalid> wrote:
There's no infrastructure for displaying approximate line numbers in the
Error Console and there's no infrastructure for letting the JS and CSS
parsers know that they got an approximate line number.
Mike Shaver
Yes, we would have to add that. Given the number of cases in which we
are seeing the "probably near" margins of error, it sounds worthwhile
from a developer ergonomics perspective.
Mike
John J. Barton
If we have the resources to change this code, let's just fix the line
number system. I've already succeeded in correcting the line numbers for
eval() in Firebug so we know it's not impossible.
jjb
John J. Barton
I think this feature could be added easily if we implemented support for
"compilation units".
The current callback for compilation in jsd is pathetic. For every
function compiled, you get a call giving the jsdIScript of the function.
But you don't get the window of the compile, the stack frame of the
compile, the source of the compile etc. Firebug has some truly awful
code to work around this, including setting breakpoints on every outer
global file function call.
Bug 379410 hints at a much better solution. By adding a callback for the
entire compilation unit, the natural information will be available
together. By compilation unit I mean anything sent to the compiler:
script tag content, script src= file, document.write buffer, eval
buffer, HTML element handler string, etc. The callback can give the
window, stack frames, buffer compiled and an array of jsdIScripts.
This would transform Firebug hacky code, make Firebug much faster,
enable support for 'new Function' and all variations of
document.write(), and -- finally returning the subject at hand -- allow
support of correct error messages for all dynamic code mechanisms. For
the last case we need only save the buffers keyed by a dynamic URL and
use that URL in error reports. The error console would not need to be
changed. Viewsource etc would all work.
jjb
Clint Talbert
> John J. Barton wrote:
>> Mike Shaver wrote:
>>> On Wed, Nov 11, 2009 at 10:26 AM, Henri Sivonen <hsiv...@iki.fi> wrote:
>>>> In article <RZWdnZRppuh6UmfX...@mozilla.org>,
>>>> Mark Tyndall <moz_...@tyndall.org.invalid> wrote:
>>>>
> The current callback for compilation in jsd is pathetic. For every
> function compiled, you get a call giving the jsdIScript of the function.
> But you don't get the window of the compile, the stack frame of the
> compile, the source of the compile etc. Firebug has some truly awful
> code to work around this, including setting breakpoints on every outer
> global file function call.
>
> Bug 379410 hints at a much better solution. By adding a callback for the
> entire compilation unit, the natural information will be available
> together. By compilation unit I mean anything sent to the compiler:
> script tag content, script src= file, document.write buffer, eval
> buffer, HTML element handler string, etc. The callback can give the
> window, stack frames, buffer compiled and an array of jsdIScripts.
Not trying to derail this thread, but I have a quick question. Would
these compilation units allow us to do better JavaScript code coverage
analysis? We currently do it by hacking a tool for JavaScript code
coverage that was originally intended to be used on websites.
Thanks,
Clint
John J Barton
Yes, because currently you cannot easily assign all of the functions
that are compiled to their owning windows. Given the list of compilation
units per window from this api, you can turn on the profiler, run the
test driver, then walk the compilation units and issue the coverage
report based on the time marks on each jsdIScript.
jjb