navigator.js has this code: 1925 function checkForDirectoryListing() 1926 { 1927 if ( "HTTPIndex" in content && 1928 content.HTTPIndex instanceof Components.interfaces.nsIHTTPIndex ) { 1929 content.defaultCharacterset = getMarkupDocumentViewer().defaultCharacterSet; 1930 } 1931 } which come from bug 28787. It seems to me that the left-hand side of the assignment hasn't worked in a long time. Once bug 871161 lands, the right-hand side of the assignment stops working, too.

(In reply to Henri Sivonen) > navigator.js has this code: > 1929 content.defaultCharacterset = > getMarkupDocumentViewer().defaultCharacterSet; > > It seems to me that the left-hand side of the assignment hasn't worked in a > long time. It should eventually call through to nsHTTPIndex::SetEncoding although I haven't tried it to see whether it still works yet.

Well, the good news is that it does call SetEncoding. The bad news is that I don't know any FTP sites with non-ascii file names to test the encoding with.

FWIW, nsDirIndexParser initializes mEncoding to the locale-specific fallback encoding by C++. Does this end up overwriting that value? If so, why bother? Firefox doesn't.

(In reply to Henri Sivonen from comment #3) > FWIW, nsDirIndexParser initializes mEncoding to the locale-specific > fallback encoding by C++. Does this end up overwriting that value? At least in the file: case, it doesn't, but it makes no difference anyway. Still no idea about the ftp: case yet though.

The call to nsHTTPIndex::SetEncoding unfortunately happens after the first call to nsDirIndexParser::SetEncoding. This means that the top-level directory of an FTP listing always decodes in ISO-8859-1. The encoding set on the nsHTTPIndex then takes affect for subdirectories. However in a comedy of errors the code in navigator.js itself happens after the call to nsHTTPIndex::SetEncoding so the default character set is completely ignored. If I fix the ordering of the calls, then I can change the character set from the menu and it will propagate to the subdirectory listing as expected. Is there a better way of retrieving the user selected character set? I can try to fix the ordering of the calls in a separate bug.

(In reply to neil@parkwaycc.co.uk from comment #5) > Is > there a better way of retrieving the user selected character set? When the user has chosen an override from the menu, the label of the choice is returned by the forcedCharset property of the top-level docshell.