If you think a bug might affect users in the 57 release, please set the correct tracking and status flags for Release Management.

navigator.js has bogus-looking handling of character encoding in the nsIHTTPIndex case

NEW
Unassigned

Status

SeaMonkey
General
4 years ago
4 years ago

People

(Reporter: hsivonen, Unassigned)

Tracking

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

4 years ago
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.
(Reporter)

Updated

4 years ago
See Also: → bug 871161

Comment 1

4 years ago
(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.

Comment 2

4 years ago
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.
(Reporter)

Comment 3

4 years ago
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.

Comment 4

4 years ago
(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.

Comment 5

4 years ago
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.
(Reporter)

Comment 6

4 years ago
(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.
You need to log in before you can comment on or make changes to this bug.