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.