Closed Bug 12085 Opened 25 years ago Closed 25 years ago

Need Meta charset in Html editor

Categories

(Core :: Internationalization, defect, P2)

Product:
Core
Component:
Internationalization
Platform:
All
Windows NT
Type:
defect

Tracking

()

Status:
VERIFIED DUPLICATE of bug 7849

People

(Reporter: teruko, Assigned: akkzilla)

Details

After you change the charset in editor and save the file, the html file does not contain HTTP META charset. Steps of reproduce 1. Open the editor 2. Select menu View|Character set->Japanese(Shift_JIS) 3. Type Japanese character 4. Select menu File|Save as to save the file 5. Look at the file you saved in step #4 from notepad In the header section, <meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS"> should be there.
Priority: P3 → P2
Status: NEW → ASSIGNED
Target Milestone: M13
this is a known problem, but i'm not sure where it falls in our priorities for the next two months. i'm going to tentatively schedule it for M13, but i'm open to suggetions.
Assignee: ftang → tague
Status: ASSIGNED → NEW
i'm going to reassign this to me, sicne it is related to the charset, save-as, and high-level conversion issues that i am working on. it's also editor related functionality, so i'll deal.
Status: NEW → ASSIGNED
Target Milestone: M13 → M11
Assignee: tague → buster
Status: ASSIGNED → NEW
this is html code generation, please reassign to the appropriate person in the editor
Assignee: buster → akkana
I'm not sure what the issue is here, and it sounds like Tague has a pretty good handle on it. Could you please get together with Akkana since she owns editor output and describe to her what needs to get done? I'll tentatively assign it to akkana, but you and her should get together and decide what really needs to get done and who should do it. Also, please work with her to prioritize it properly. Should the component be "editor?"
Yes, I'm the editor output person, but I don't understand this bug. Is it just a matter of the output sink writing out a meta tag specifying the charset that's been passed in in the stream interface if it isn't null?
this is a function (or needs to be) of the HTML output sink --- email paste ---- I was told to reassign this to the editor group. Normally, html code generation is not our groups reponsibility, but falls historically to the editor. Since, your group owns the HTML output sink it seems to still be a valid fit. The basic problem is that the HTML outputsink is not adding META charset tag when outputing HTML. The meta charset needs to get added when writing out the <head> elements of a page, and needs to contain the correct charset name for the encoding that is being used for the output.
My question remains: where should I get the charset to write to the meta tag? I need to know that in order to fix this bug. Do I do this only in the case where we've been called via the stream API with charset tag specified, and that's the charset which should be written into the meta tag? Or is there some API I should call to get the right charset string?
the charset information should be availble from the nsIDocument. Look at nsEditor::GetDocumentCharset. /t
We don't have a document by the time the output is being generated (and we didn't necessarily ever have one to begin with, as far as the output sink knows). Are there cases where we want output to have a meta tag specifying charset but we did NOT pass the charset in to the nsHTMLContentSinkStream via the stream API? I.e. does the output sink need yet another API to specify output charset (different from the charset being passed in in the stream API)?
the html output sink needs to write the meta-charset tag for whatever encoding it is using for the output. the xif comes into the html output sink as unicode and gets converted to a legacy encoding -- the meta-charset needs to match the output encoding. the information is originally availible from the nsIDocument, it's being carried along in the output process
Status: NEW → ASSIGNED
I am going to assume that "carried along in the output process" means that it's the charset string that's already being passed to the output sink, and will fix accordingly. If there's some case that this doesn't address, someone who understands when that happens will have to reopen or open a separate bug.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Fixed for the case indicated (which does fix the Save As case mentioned at the top of this bug).
Status: RESOLVED → REOPENED
I tested this in 9-08 Win build. The meta charset whenever I selected menu is in the editor. However, there is an extra meta charset for UTF-8 also. <meta http-equiv="Content-Type" content="text/html; charset=Shift_JIS"> <title>xxxxxxx</title> <meta http-equiv="Content-Type" content="text/html; charset=utf-8"> When I look at this page in the browser, the Japanese characters are not displayed correctly. I need to reopen this bug.
Resolution: FIXED → ---
There are a few problems here and I'm not sure how they should be solved. 1. The reason for the two charsets is that the charset override from the menu doesn't do anything to remove the meta tag node in the document which sets the charset. This seems like a bug, since it leaves us with two conflicting charsets. Overriding the charset should change the meta charset tag in the document if that meta tag is going to cause problems when it's written out. The output sink could potentially hack around this, by trying to detect the existing charset tag if we're overriding, and not output the old charset tag in that case; but the problem is that there are lots of different meta tags, so how do we detect the one we shouldn't be outputting? Doing a string match on anything with "charset" in it seems like the wrong thing to do when we previously had that information accessible in the tree. I need some input from people who understand meta tags and charsets better than I do.
Status: REOPENED → RESOLVED
Closed: 25 years ago → 25 years ago
Resolution: --- → DUPLICATE
Turns out 7849 says that changing the charset menu should change the meta tag in the document. Adding a new charset line in the output sink stream was the wrong thing -- the meta tag in the document is the right way to do this -- and I'm going to back out the output sink code. Duping this bug to 7849 since fixing that will also fix this problem. *** This bug has been marked as a duplicate of 7849 ***
checked for duplication with bug # 7849
Status: RESOLVED → VERIFIED
Verified as dup.
You need to log in before you can comment on or make changes to this bug.