Last Comment Bug 246454 - content-language HTML equivalent doesn't work
: content-language HTML equivalent doesn't work
Status: VERIFIED FIXED
: helpwanted
Product: SeaMonkey
Classification: Client Software
Component: General (show other bugs)
: Trunk
: All All
: -- normal (vote)
: ---
Assigned To: Martijn Wargers [:mwargers] (not working for Mozilla)
:
Mentors:
http://annevankesteren.nl/test/css/s/...
Depends on:
Blocks:
  Show dependency treegraph
 
Reported: 2004-06-12 00:34 PDT by Anne (:annevk)
Modified: 2004-11-22 17:25 PST (History)
5 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---


Attachments
This seems to work for me (5.04 KB, patch)
2004-06-17 14:03 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details | Diff | Splinter Review
Improved(?) version (3.56 KB, patch)
2004-07-12 08:55 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
no flags Details | Diff | Splinter Review
More improved(?) version (3.55 KB, patch)
2004-07-12 13:56 PDT, Martijn Wargers [:mwargers] (not working for Mozilla)
bzbarsky: review+
bzbarsky: superreview+
Details | Diff | Splinter Review

Description Anne (:annevk) 2004-06-12 00:34:45 PDT
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 Jo Hermans 2004-06-12 04:09:09 PDT
Build 2004061108 (Seamonkey)

Works for me if the language was present in the list in
Preferences->Navigator->Languages.

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 Anne (:annevk) 2004-06-12 04:17:16 PDT
Not at all. The following two test cases should output exactly the same with
default settings afaik:

 * <http://annevankesteren.nl/test/css/s/p-c/lang-005.htm.php>
 * <http://annevankesteren.nl/test/css/s/p-c/lang-007.htm>
Comment 3 Boris Zbarsky [:bz] 2004-06-12 16:14:20 PDT
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
Comment 4 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-06-17 14:03:49 PDT
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.
Comment 5 Boris Zbarsky [:bz] 2004-07-12 03:20:11 PDT
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 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-07-12 08:55:27 PDT
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.
Comment 7 Christian :Biesinger (don't email me, ping me on IRC) 2004-07-12 09:22:01 PDT
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?) 
Comment 8 Boris Zbarsky [:bz] 2004-07-12 10:50:35 PDT
> 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
http://lists.w3.org/Archives/Public/public-css-testsuite/2004Jun/0002.html).  It
was supposed to have been filed, but looks like that hasn't happened.
Comment 9 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-07-12 13:56:39 PDT
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).
Comment 10 Boris Zbarsky [:bz] 2004-07-12 15:32:47 PDT
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.
Comment 11 Martijn Wargers [:mwargers] (not working for Mozilla) 2004-07-15 01:58:58 PDT
Ok, I've tested this now. It seems to work just fine for the testcases. And the
tree is reopened, so...
Comment 12 Boris Zbarsky [:bz] 2004-07-15 16:02:04 PDT
checked in.
Comment 13 Anne (:annevk) 2004-07-18 12:54:13 PDT
Thanks Martijn! (And Boris for checking it in.)

Note You need to log in before you can comment on or make changes to this bug.