Closed Bug 91933 Opened 25 years ago Closed 21 years ago

Having my name in a .dtd/.properties file ruins it

Categories

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

Product:
Core
Component:
DOM: HTML Parser
Type:
defect

Tracking

()

Status:
RESOLVED INVALID
Milestone:
Future

People

(Reporter: hwaara, Assigned: mrbkap)

Details

(Keywords: intl)

If I put my name in a comment, in a .properties/.dtd file -- when the XUL tries to load it, it doesn't get the strings. So the dialog that is supposed to use the strings ends up blank! I suspect this is all because of that 'å' in my name. :( This has caused me a lot of grief, and I'm sure i10n people contributing aren't too comfortable with it either. (Note that the name is in a comment!)
The interesting thing about this bug (other than it took me 2 hours to figure it was hwaara's name) is that no errors were given about missing properties. Hwaara, if you add your name as a comment in the middle of a .dtd/.properties file (not at the end of the header as is usually done), are the entries before your name displayed and those after it not?
I haven't tried but I think the whole file is omitted.
Keywords: intl
Hwaara: Could you attach a testcase and briefly explain the steps to reproduce?
CCing nhotta - Could be a problem with the unicode coverter!
The only step to reproduce is to attach a DTD to a XUL file (like we do everywhere), and put my name in the contributors field. That will, in all cases I've tried, make the XUL file not read the DTD at all!
Håkan: This bug could be very well related to bug 94903. If you have a build could you please apply the patch, in bug 94903, and test it. thanx.
Status: NEW → ASSIGNED
I applied the patch, and then added Håkan to a comment within a dtd file. The dtd seems to have loaded but I might not be testing something correctly. I am seeing some problems with a properties file not being loaded (??!!).
I was wrong; the dtd file did not load if "Håkan" was listed as a contributor in a comment in the dtd file; the fix in bug #94903 did not help this bug.
QA Contact: bsharma → moied
Priority: -- → P2
Target Milestone: --- → mozilla0.9.5
--> 0.9.6
Target Milestone: mozilla0.9.5 → mozilla0.9.6
Harish, you might be interested in the (upcoming) fix for bug 106843 that will fix a regression which makes us not load a stylesheet if ny name is there. The testcase is pretty simple in this bug, add my name to a DTD and see the parsing fail. Is there anything I can do to help you fix this?
Håkan: I still haven't got a chance to look into this bug ( since my primary focus is on performance related issues ). Will try to fix this bug for 0.9.6. Sorry!
If I understand correctly the problem here is that all out XUL is in UTF-8 and the å in Håkan's name is illegal in UTF8. Therefore either Håkan needs to UTF-8 encode his name when adding it to a DTD or he needs to add 'charset="ISO-8859-1"' to the XML decl of all XUL files in whose DTDs his name appears. If I understand correctly, doing anything else is producing invalid XML. Note that adding 'charset="ISO-8859-1"' will effectively prohibit localization to any language the characters of which cannot be expressed in ISO-8859-1, so it is not a viable option in my opinion. If I may ask, why was the assertion in nsUTF8ToUnicode::Convert commented out? If it asserted on failure, this problem would have been diagnosed long ago...
Bz, adding my name to a xul file works fine, it's just dtd/properties files that cause problems.
Interesting side note. The parser _does_ handle problems of this sort, as far as I can tell. See http://lxr.mozilla.org/seamonkey/source/htmlparser/src/nsScanner.cpp#343 So I'm not sure what's up here exactly, but it's different from bug 106843, where we reject any input that fails to convert out of hand.
Håkan, did you encode the string in the property file using \uXXXX form?
I didn't encode or do anything advanced like that: I just put my name in the contributors field as I always do when I do substantial changes to a file, using notepad.exe and whoops, the DTD was now not read at all!
\uXXXX has to be used in .property files for non ASCII characters. Here is a document (see "String Resource File Format"). http://www.mozilla.org/projects/intl/string-resources.html
Nhotta, note that this is inside a *comment*. Why do I have to play around with \uXXX stuff if I just want this to display correctly when you open the source in a text-editor? Comments should be ignored, and it makes no sense to hand-code unicode characters like this if the result will only be inside a xml comment, imho.
fwiw. hwaara is using 9x's notepad instead of NT's notepad (i'm almost certain 2k's can output UTF8).
Håkan, which file are you trying to edit and have the problem?
Out of time :-( Moving to 0.9.7
Target Milestone: mozilla0.9.6 → mozilla0.9.7
--> 0.9.8
Target Milestone: mozilla0.9.7 → mozilla0.9.8
Out of time. Mass move to 0.9.9
Target Milestone: mozilla0.9.8 → mozilla0.9.9
Mass moving to 1.1.
Target Milestone: mozilla0.9.9 → mozilla1.1
[was 1.1alpha]
Target Milestone: mozilla1.1alpha → Future
Håkan, the internal markup structure of a file (XML, XML DTD, or whatever) is on a completely different plane from character encoding issues. As it stands, an XML DTD without explicitly specified character set should, per RFC 3023 and XML 1.0, be treated as UTF-8. Since you're trying to put an ISO-8859-1 character in it, it simply doesn't work. We could perhaps handle it more gracefully, but you need to use Unicode-supporting software if you're going to try to put non-ASCII characters into these files.
Assignee: harishd → mrbkap
Status: ASSIGNED → NEW
Using: <!DOCTYPE window [ <!ENTITY button.label "Håkan"> <!ENTITY testtitle "Bug 91933 Window"> ]> within an .xul file works fine. As Håkan said, for a test case just alter an existing .dtd/.properties file by adding a comment or changing one of the entities.
On IRC Boris told me that our current behavior is basically correct. In fact, that we don't fail on invalid characters in the actual XML file is a bug (bug 174351) that should be fixed. While it isn't nice that we fail silently, it's probably the most correct thing to do. Marking this INVALID, based on this.
Status: NEW → RESOLVED
Closed: 21 years ago
Resolution: --- → INVALID
You need to log in before you can comment on or make changes to this bug.