47416 - Error message doesn't include the name of the faulty file

Status: VERIFIED FIXED

(Core :: XML, defect, P3)

Description

[rbs]

When at startup, one of the XUL files has an error in it (e.g., typo, 
or invalid entity), it is very difficult to track down the problem
in optimized builds that don't have a debug console. Using
the -console option doesn't help in this case because the name of
the file is not reported in the console of optimized builds. 

The popup window only shows:

XML Parsing Error
Line Number #, Column #

It will be helpful to also include the name of the faulty file to
help pinpoint the source of the problem:

XML Parsing Error
File: ...
Line Number #, Column #

Comment 1

[Nisheeth Ranjan]

Marking helpwanted and setting nsbeta3-.  I'd love it if somebody could put a
patch together.  I will try to if I get time, but only after higher priority
beta3+ bugs get fixed.

Comment 2

[rbs]

Had a first look to see if I could do something useful regarding this one. I saw
how the error is created in nsExpatTokenizer::PushXMLErrorTokens() using the
following struct defined in nsPaserError.h

struct _nsParserError {
  PRInt32 code;
  PRInt32 lineNumber;
  PRInt32 colNumber;  
  nsString description;  
  nsString sourceLine;
} nsParserError;

So, it looks like adding "nsString sourceFileName;" could do the trick.  
The existing fields in the struct are filled with readily available functions. 
Is there a readily available funtion to also get the filename (absURL?).

Comment 3

[Nisheeth Ranjan]

http://lxr.mozilla.org/mozilla/source/htmlparser/src/nsWellFormedDTD.cpp#737 
shows that the file name does get printed out.  Roger, are you still seeing 
error messages which do not contain the file name?

I'm futuring this bug to get it off my radar.  Please reset the target milestone 
to "---" to bring this bug to my attention.  Thanks.

Comment 4

[rbs]

Yep, I still see the problem. In fact, things are OK in debug builds where the 
printf that you showed are executed. It is in optimized builds that the problem
happens because the printf are not in effect, and the filename isn't added to
the nsParserError from which the error is reported in the content window.

Note to QA folks: To reproduce the problem, in an optimized build make a typo in
one of the critical XUL files (or better, ask someone else to do it so that it
is hidden). Then, it is very difficult to find the typo because the content
window only indicates that there is a problem at line# and col#, without telling
in which file; and there are tones of XUL files around...

Comment 5

[Heikki Toivonen (remove -bugzilla when emailing directly)]

Moving to 0.9.2, but might still be fixed before 0.9.1 deadline. Should be
simple fix.

Comment 6

[rbs]

Have the fix. Should be good enough although strings are hardcoded and not 
localized. Need your r/sr (should be a no brainer).

Index: nsExpatTokenizer.cpp
===================================================================
RCS file: /cvsroot/mozilla/htmlparser/src/nsExpatTokenizer.cpp,v
retrieving revision 1.82
diff -u -r1.82 nsExpatTokenizer.cpp
--- nsExpatTokenizer.cpp        2001/04/18 05:58:51     1.82
+++ nsExpatTokenizer.cpp        2001/05/15 12:00:41
@@ -303,6 +303,8 @@

   if (aError) {
     aErrorString.Append(aError->description);
+    aErrorString.AppendWithConversion("\nLocation: ");
+    aErrorString.Append(aError->sourceURL);
     aErrorString.AppendWithConversion("\nLine Number ");
     aErrorString.AppendInt(aError->lineNumber, 10);
     aErrorString.AppendWithConversion(", Column ");
@@ -402,6 +404,7 @@
     // Adjust the column number so that it is one based rather than zero based.

     error->colNumber = XML_GetCurrentColumnNumber(mExpatParser) + 1;
     error->description.AssignWithConversion(XML_ErrorString(error->code));
+    error->sourceURL = mState->scanner->GetFilename();
     if (!aIsFinal) {
       PRInt32 byteIndexRelativeToFile = 0;
       byteIndexRelativeToFile = XML_GetCurrentByteIndex(mExpatParser);
Index: nsParserError.h
===================================================================
RCS file: /cvsroot/mozilla/htmlparser/src/nsParserError.h,v
retrieving revision 1.3
diff -u -r1.3 nsParserError.h
--- nsParserError.h     1999/11/06 03:22:24     1.3
+++ nsParserError.h     2001/05/15 12:00:41
@@ -41,6 +41,7 @@
   PRInt32 colNumber;
   nsString description;
   nsString sourceLine;
+  nsString sourceURL;
 } nsParserError;

 #endif

Comment 7

[Heikki Toivonen (remove -bugzilla when emailing directly)]

r=heikki

Is there a bug on making XML parser messages localizable?

Comment 8

[rbs]

I have just filed bug 80959 about L10n problems.

Comment 9

[rbs]

jst, can you sr= tp finish off this one, thanks.

Comment 10

[Johnny Stenback (:jst)]

sr=jst

Comment 11

[rbs]

Checked-in. Resolving as FIXED.

Comment 12

[Chris Petersen]

Marking verified per last comments.