Closed Bug 525222 Opened 10 years ago Closed 9 years ago

XML errors possible on file:// listings

Categories

(Core :: Networking, defect)

x86
macOS
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0b7
Tracking Status
blocking2.0 --- -
status2.0 --- wanted

People

(Reporter: bzbarsky, Assigned: Ehsan)

References

Details

(Whiteboard: wanted1.9.3)

Attachments

(1 file, 1 obsolete file)

See bug 500282 comment 17.

This is a regression from bug 348233.

Can we just go back to HTML now that we have :-moz-locale-dir?
blocking2.0: --- → ?
Flags: blocking1.9.2?
Not a regression from 3.5, so not a blocker, as much as it sucks. Would take a fix, especially if Ehsan isn't working on anything else more critical.
Flags: wanted1.9.2+
Flags: blocking1.9.2?
Flags: blocking1.9.2-
Attached patch WIP (obsolete) — Splinter Review
This patch reverts everything back to HTML except the test.

The problem here is that :-moz-locale-dir doesn't work in HTML.  bz, do we want it to be accessible to HTML (and content)?  If so, should it just mimic the behavior in XUL or do we need a new behavior here?
CCing Neil as he might be able to provide us with insight here.
Blocks: 500282
Hmm.  IsDocumentRightToLeft is indeed implemented on nsXULDocument.  

This does raise an interesting question, though.  Instead of generating

  buffer.AppendLiteral("</head>\n<body dir=\"&locale.dir;\">\n<h1>");

as we do now, can we not generate either dir="ltr" or dir="rtl" depending on the locale information nsXULDocument::IsDocumentRightToLeft uses?  Then we wouldn't even need to use :-moz-locale-dir; we could keep our existing selectors.
I thought about that, but I didn't know that it was possible to get access to the window's nsXULDocument from nsIndexToHTML.  How can I do that?
Why do you need the window's nsXULDocument?  If we just want to replicate what &locale.dir does, wouldn't just doing the 

  // otherwise, get the locale from the chrome registry

codepath from nsXULDocument::IsDocumentRightToLeft work?
Probably factoring that out into an nsContentUtils method, too.
Not blocking 1.9.3 on this, but would love to see it fixed.
blocking2.0: ? → -
Whiteboard: wanted1.9.3
So the XML errors can happen on FTP listings too.  We really need to fix this... :(
This causes XML errors on filenames containing '&' too.

Ehsan, is there anything at all I can do to make this easier to fix?
Duplicate of this bug: 603113
Attached patch Patch (v1)Splinter Review
Attachment #409717 - Attachment is obsolete: true
Attachment #482616 - Flags: review?(bzbarsky)
Attachment #482616 - Flags: approval2.0?
Comment on attachment 482616 [details] [diff] [review]
Patch (v1)

r=me
Attachment #482616 - Flags: review?(bzbarsky) → review+
Attachment #482616 - Flags: approval2.0? → approval2.0+
Whiteboard: wanted1.9.3 → wanted1.9.3 [needs landing]
http://hg.mozilla.org/mozilla-central/rev/09adce374ccd
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
Whiteboard: wanted1.9.3 [needs landing] → wanted1.9.3
Target Milestone: --- → mozilla2.0b8
Target Milestone: mozilla2.0b8 → mozilla2.0b7
Duplicate of this bug: 544685
Duplicate of this bug: 725749
Duplicate of this bug: 531524
You need to log in before you can comment on or make changes to this bug.