XML errors possible on file:// listings

RESOLVED FIXED in mozilla2.0b7

Status

()

Core
Networking
RESOLVED FIXED
8 years ago
6 years ago

People

(Reporter: bz, Assigned: Away for a while)

Tracking

Trunk
mozilla2.0b7
x86
Mac OS X
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.9.2 -
wanted1.9.2 +
in-testsuite +

Firefox Tracking Flags

(blocking2.0 -, status2.0 wanted)

Details

(Whiteboard: wanted1.9.3)

Attachments

(1 attachment, 1 obsolete attachment)

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-
(Assignee)

Comment 2

8 years ago
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?
(Assignee)

Comment 3

8 years ago
CCing Neil as he might be able to provide us with insight here.
(Assignee)

Updated

8 years ago
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.
(Assignee)

Comment 5

8 years ago
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
status2.0: --- → ?
status2.0: ? → wanted
Blocks: 552152
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
(Assignee)

Comment 12

7 years ago
Created attachment 482616 [details] [diff] [review]
Patch (v1)
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+

Updated

7 years ago
Attachment #482616 - Flags: approval2.0? → approval2.0+
(Assignee)

Updated

7 years ago
Whiteboard: wanted1.9.3 → wanted1.9.3 [needs landing]
(Assignee)

Comment 14

7 years ago
http://hg.mozilla.org/mozilla-central/rev/09adce374ccd
Status: NEW → RESOLVED
Last Resolved: 7 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.