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: --- → ?
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.
Created attachment 409717 [details] [diff] [review] WIP 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.
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: ? → -
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?
Created attachment 482616 [details] [diff] [review] Patch (v1)
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]
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Resolution: --- → FIXED
Whiteboard: wanted1.9.3 [needs landing] → wanted1.9.3
Target Milestone: --- → mozilla2.0b8
Target Milestone: mozilla2.0b8 → mozilla2.0b7
You need to log in before you can comment on or make changes to this bug.