content-language HTML equivalent doesn't work



13 years ago
13 years ago


(Reporter: annevk, Assigned: Martijn Wargers (dead))




Firefox Tracking Flags

(Not tracked)




(1 attachment, 2 obsolete attachments)



13 years ago
It seems that the 'content-language' HTTP header isn't supported as META element:

 <meta http-equiv="content-language" content="x-example">

The code should be changed to make sure we support both.

Comment 1

13 years ago
Build 2004061108 (Seamonkey)

Works for me if the language was present in the list in

If I add 'x-example' in the list, I see the green line. If I change the language
to 'nl' (which is in my list), I also see green. When I change it to 'de' (not
in my list), I see a red line. When I add 'de' or 'de-at' to the list, I see the
green line again.

Isn't this the expected behaviour ?

Comment 2

13 years ago
Not at all. The following two test cases should output exactly the same with
default settings afaik:

 * <>
 * <>
Anne, you could move content-language header processing out of the document and
into the content sink.  That would fix this.  See
nsContentSink::ProcessHTTPHeaders and nsDocument::RetrieveRelevantHeaders
Keywords: helpwanted

Comment 4

13 years ago
Created attachment 151048 [details] [diff] [review]
This seems to work for me

Well, this seems to work for me.
Because I absolutely don't know what I'm doing, this is very likely done in the
wrong way.
Martijn, that looks like a pretty good start to me!  I'm not so sure we want to
make that member public -- I'd rather we either added a setter or moved the
actual setting of the string into nsDocument::SetHeaderData.

Comment 6

13 years ago
Created attachment 152952 [details] [diff] [review]
Improved(?) version

Yes, I already thought that was the sucking part, but I didn't know better.
Perhaps this one is better. It seems to be working fine for me.
I did use NS_ConvertUCS2toUTF8(aData). Not really knowing if this is correct.
The other option, adding a setter, I don't think I know how to make that one.


13 years ago
Attachment #151048 - Attachment is obsolete: true
a setter would be a function like "void SetContentLanguage(const nsACString& 
aLanguage) { mContentLanguage = aLanguage; }" 
(can't comment on the patch you attached as I don't know this code. 
although... shouldn't you still read the default language pref?) 
> I did use NS_ConvertUCS2toUTF8(aData).

Why?  You should have been able to keep using CopyUTF16toUTF8, no?

> shouldn't you still read the default language pref?

Actually, no.  The fact that we read it is a bug (see  It
was supposed to have been filed, but looks like that hasn't happened.

Comment 9

13 years ago
Created attachment 152979 [details] [diff] [review]
More improved(?) version

Ehm, yes. I didn't know why I did not use that in the first place. 
This does compile, although I did not test it, because then I have to compile
the whole build again (which I'll do anyway but that takes a while).

I didn't know I would fix another bug with this patch, but now I can see that.
That was completely unintentional (and I don't even know whether I find that
rule logical).
Attachment #152952 - Attachment is obsolete: true
Comment on attachment 152979 [details] [diff] [review]
More improved(?) version

r+sr=bzbarsky.	Do be sure to test this, though, and ping me to check this in
once the tree reopens, please.
Attachment #152979 - Flags: superreview+
Attachment #152979 - Flags: review+

Comment 11

13 years ago
Ok, I've tested this now. It seems to work just fine for the testcases. And the
tree is reopened, so...
Assignee: general → m.wargers
Ever confirmed: true
checked in.
Last Resolved: 13 years ago
Resolution: --- → FIXED

Comment 13

13 years ago
Thanks Martijn! (And Boris for checking it in.)
OS: Windows XP → All
Hardware: PC → All
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.