Closed Bug 44094 Opened 25 years ago Closed 25 years ago

XML parsing error message shows column off by 1

Categories

(Core :: XML, defect, P3)

x86
Linux
defect

Tracking

()

VERIFIED FIXED
mozilla0.9

People

(Reporter: demian.godon, Assigned: nisheeth_mozilla)

Details

(Whiteboard: [nsbeta3-] relnote-devel)

Attachments

(2 files)

Load wf_constraint_tag_empty.xml (from mozilla test page) Result --> XML parsing error message is displayed showing the offending line number and column. In this case it claims the column is 27 when it looks to me like it should be 28. IE 5 reports the error as being on position 28.
I loaded the same xml file and got the same results. The reason for this is we assign the first column item a value of "0" instead "1" like apparently IE does.
Status: UNCONFIRMED → NEW
Ever confirmed: true
This is a trivial fix and will prove to be an annoying problem for XML page authors. Nominating for nsbeta3
Status: NEW → ASSIGNED
Keywords: nsbeta3
Might pull this one in if I fix my other beta3+ bugs. But, right now, marking beta3- and adding relnote keyword. This bug has been marked nsbeta3- 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, but do not clear the nsbeta3- nomination.
Keywords: relnote3
Whiteboard: [nsbeta3-]
Whiteboard: [nsbeta3-] → [nsbeta3-] relnote-devel
Keywords: nsbeta1
Nom. nsbeta1. Let's change this to be consistent with the behavior of IE. Neither index value is "more correct" than the other, and cross-browser off-by-one inconsistencies are just plan annoying and help no one, so we'll remove one more point of confusion from developers' lives if we work the same as IE.
Setting target milestone to mozilla0.8.
Target Milestone: --- → mozilla0.8
nisheeth: if you're busy, i'll take this (just let me know what you had in mind as a fix).
I'm really sorry for not getting this onto the 0.8 train. This will be the first thing that lands for 0.9. I won't even attempt to make an excuse for this one! This is trivial to fix.
Target Milestone: mozilla0.8 → mozilla0.9
Attached patch Patch for fixSplinter Review
patch (id=24919) looks good. r=harishd
sr=vidur. Not a 0.8 stopper, I'm sure.
Yeah, wait for after we re-open for 0.8.
Fix checked in.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Marking verified fixed in the Feb 26th build.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Created:
Updated:
Size: