Closed Bug 16934 Opened 25 years ago Closed 24 years ago

[Strict DTD]line breaks within tags not counted towards JS errors

Categories

(Core :: DOM: HTML Parser, defect, P3)

Product:
Core
Component:
DOM: HTML Parser
Platform:
x86
Linux
Type:
defect

Tracking

()

Status:
CLOSED INVALID
Milestone:
Future

People

(Reporter: dbaron, Assigned: harishd)

References

(
URL
)

Details

(Keywords: relnote, Whiteboard: [nsbeta3-] relnote-devel)

Attachments

(1 file)

test case described in bug
514 bytes, text/html
Details 
This is a separate bug filed on the complex testcase from bug 15992, which is
now (otherwise) fixed.

DESCRIPTION:  A line break that occurs within a tag isn't counted towards
line-number reporting of JS errors.

I am marking severity as 'blocker' because this blocks developers from using
Mozilla to develop JS.  See also related bugs: bug 8045, bug 10593,
bug 15992 (fixed).

STEPS TO REPRODUCE:
 * load attached test case
 * look at the text window

ACTUAL RESULTS:
 * the line numbers given by the errors are 10, 17, and 24.

EXPECTED RESULTS:
 * the line numbers given by the errors should be 10, 18, and 29. (as the dump
statements say)

DOES NOT WORK CORRECTLY ON:
 * Linux, apprunner, 1999-10-20-11-M11

ADDITIONAL INFORMATION:
 * please verify the URL above,
http://bugzilla.mozilla.org/showattachment.cgi?attach_id=2064 , when verifying
this bug.  Doing so for bug 15992 was the only reason this one was caught.
There could be other problems.
Assignee: rickg → harishd
Assigning to myself
Severity: normal → blocker
I didn't mark severity as I said I did.  Doing so now...
Status: NEW → ASSIGNED
Here is the reduced case:

1. <HTML>
2.  <BODY>
3.   <TABLE>
4.    <TR>
5.     <TD><A
6.      HREF="foo.htm">Trademark</A>
7.     </TD>
8.    </TR>
9.   </TABLE>
10. </BODY>
11.</HTML>
12. <SCRIPT>
13.  dump("Should give error on line 14:\n");
14.  somefuntion()
15. </SCRIPT>

In line: 5 the new line after <A is not accounted for.
Blocks: 17432
Target Milestone: M11
Target Milestone: M11 → M12
David, I fixed this a while back but was not able to checkin due to other
changes in my tree!!.  Will checkin as soon as the tree opens for M12.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Corrected the glitch. Marking FIXED.
No longer blocks: 17432
I'm reopening this as this testcase now produces 4 javascript errors that all 
say line 0

2000-07-07-10-M17
Status: RESOLVED → REOPENED
Resolution: FIXED → ---
Janc, did you try the attachment or my reduced case?

If it's the attachment then try removing the DOCTYPE.

This is probabaly a legit bug in STRICT DTD.
Status: REOPENED → ASSIGNED
Nominating for beta3.
Keywords: nsbeta3
Target Milestone: M12 → M18
Marking nsbeta3+ because we want to be a usable development platform and 
correctness of line number information for JS errors is very useful for web 
developers and dogfood.
Whiteboard: [nsbeta3+]
This is a hard call for us to make, but we are overbudget on beta 3 bugs, so we 
are futuring this one.

This bug has been marked "future" because the original netscape engineer working 
on this is over-burdened. If you feel this is an error, that you or another
known resource will be working on this bug,or if it blocks your work in some way 
-- please attach your concern to the bug for reconsideration.
Keywords: relnote
Target Milestone: M18 → Future
Whiteboard: [nsbeta3+] → [nsbeta3-]
I have verified that this is a bug in the Strict DTD.
Summary: line breaks within tags not counted towards JS errors → [Strict DTD]line breaks within tags not counted towards JS errors
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-devel
Is this bug still valid now that the StrictDTD parsing has been removed? (If
this isn't applicable to CNavDTD, it doesn't make sense to relnote this.)
Nom. nsbeta1. Reporting the location of JS errors incorrectly is a *major*
inconvenience to developers. We're already asking them to update their JS to
support the W3C DOM, so we want to make the process of testing & debugging
existing/modified JS as easy as possible for them.
Keywords: nsbeta1
Eric, STRICT DTD is used only by the editor and therefore JS error location 
should not be an issue in general. In other words, STRICT DTD does not play any 
role in reporting the line # of a JS error.
Invalidating the bug. Refer to my previous comment.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 24 years ago
Resolution: --- → INVALID
updated qa contact.
QA Contact: janc → bsharma
QA Contact: bsharma → moied
Verified invalid
Status: RESOLVED → CLOSED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: