David Baron :dbaron: Reporter
	Description • 26 years ago

Error locations in linked scripts are being given incorrectly (in the text
window, of course).  There are two problems:

1) The filename is given as the name of the main document, not the file
containing the script.  NN4.x got this right.

2) The line number is a line number in the correct file (where the error is),
but it is always one number too small.

Test case will be attached (to work without downloading from bugzilla).

This bug is serious, since it makes writing of demos and testing of the DOM
difficult.  Almost marked as blocker since almost a QA-blocker.

	David Baron :dbaron: Reporter
	Comment 3 • 26 years ago

The error currently being given is:

JavaScript error: document.doctype has no properties
URL: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=391 LineNo: 2

it should be

JavaScript error: document.doctype has no properties
URL: http://bugzilla.mozilla.org/showattachment.cgi?attach_id=390 LineNo: 3

	John Bandhauer
	Comment 4 • 26 years ago

1) Changing the component. There is no 'JavaScript Debugger' for mozilla yet.

2) When doing a 'src=' include the engine is supposed to be asked to do a new
eval with a new buffer full of text and with the new filename and lineno param.
Is this not happenning?

joki, are you the right one to look at this? Is this a known bug?

the example has:
<script type="text/javascript" src="/showattachment.cgi?attach_id=390">

	joki (gone)
	Comment 5 • 26 years ago

Yeah sure, me or Vidur.  I'll take it.

	John Bandhauer
	Comment 6 • 26 years ago

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

	John Bandhauer
	Comment 7 • 26 years ago

I *knew* there was already a bug filed for this. I just couldn't find it. I kind
of like my description - and very simple test - in bug 9710. But it really says
the same thing said here.

	David Baron :dbaron: Reporter
	Comment 8 • 25 years ago

Nominating this for [DOGFOOD].  This makes debugging complicated sites near
impossible (see, for example, the recent post on mozilla-layout) and makes it
hard for QA people to figure out the DOM bugs on a given page.

	rickg
	Comment 9 • 25 years ago

Perhaps we'll make beta.

	rickg
	Comment 10 • 25 years ago

Moving to m13 because Joki seems to be distracted.

	ekrock's old account (dead)
	Comment 11 • 25 years ago

Bulk moving [testcase] code to new testcase keyword. Sorry for the spam!

	joki (gone)
	Comment 12 • 25 years ago

I suspect this won't make M14

	leger
	Comment 13 • 25 years ago

Putting dogfood in the keyword field.

	David Baron :dbaron: Reporter
	Comment 14 • 25 years ago

I previously nominated this bug for dogfood, and I don't know how I missed it
for beta1 nominations.  Since it seems like the tree will reopen for M15 before
beta1, I'm removing the DOGFOOD and PDT- markers, and nominating for beta1.  I
think one of the goals of a beta is to get developers creating content that
works on the new browser, and this bug is a major obstacle to that.

	daver
	Comment 15 • 25 years ago

Eric or Rick, can you comment on how much you need this for beta.

	ekrock's old account (dead)
	Comment 16 • 25 years ago

Painful as it is, we can release note this. Very sorry to inconvenience our 
developers, but I recommend we not PDT+ this for beta1. (Personally, I never pay 
any attention to line numbers. Reporting the filename wrong is much worse, but 
still, it's not an issue that affects consumers or reviewers.)

	David Baron :dbaron: Reporter
	Comment 17 • 25 years ago

A good place to start looking to fix this bug is the EvaluateScript call at:
http://lxr.mozilla.org/mozilla/source/layout/html/document/src/nsHTMLContentSink.cpp#4122

	John Bandhauer
	Comment 18 • 25 years ago

I'm attaching a patch that fixes this bug. We can check it in now or later.

NOTE: layout/xml/document/src/nsXMLContentSink.cpp has a similar problem that 
ought to be fixed.

	leger
	Comment 20 • 25 years ago

Putting on PDT- radar for beta1.  Putting relnote in keyword field.

	John Bandhauer
	Comment 21 • 25 years ago

moving to vidur's list. NOTE: patch attached.

	John Bandhauer
	Comment 22 • 25 years ago

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

	John Bandhauer
	Comment 23 • 25 years ago

Note that bug 30736 also has a patch (from norris) to fix this. We should decide 
which one to use and check it in.

	David Baron :dbaron: Reporter
	Comment 24 • 25 years ago

Yes, please do check this in... :-).  I was actually about to write a third
patch on 2-18 when you attached yours.  If it means anything, I was going to do
something more similar to what norris did, rather than the little null => use
Document URI hack in EvaluateScript.

This should also be fixed for XML, so don't resolve the bug quite yet...

Note also that the bug marked as a duplicate of this bug was PDT+, so this one
probably should be too...

	Johnny Stenback (:jst)
	Comment 25 • 25 years ago

Interesting, 30736 should be a dup of this (an AFAIK was marked as such) but
theres no mentioning in 30736 that it would be a dup of this?

Howeve, 30736 is fixed and AFAIK so is this, so I'll mark this a dup of 30736
in stead. (note that the testcase in this bug no longer gives a JS error since
document.documentType is not null any more if a doctype is found in the
document).


*** This bug has been marked as a duplicate of 30736 ***

	Sebastian Späth
	Comment 26 • 25 years ago

cleaning up: VERIFY duplicate