Need Meta charset in Html editor

VERIFIED DUPLICATE of bug 7849

Status

()

Core
Internationalization
P2
major
VERIFIED DUPLICATE of bug 7849
19 years ago
18 years ago

People

(Reporter: Teruko Kobayashi, Assigned: Akkana Peck)

Tracking

Trunk
All
Windows NT
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

(Reporter)

Description

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

Updated

19 years ago
Priority: P3 → P2

Updated

19 years ago
Status: NEW → ASSIGNED
Target Milestone: M13

Comment 1

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

Updated

19 years ago
Assignee: ftang → tague
Status: ASSIGNED → NEW

Comment 2

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

Updated

19 years ago
Status: NEW → ASSIGNED

Updated

19 years ago
Target Milestone: M13 → M11

Updated

19 years ago
Assignee: tague → buster
Status: ASSIGNED → NEW

Comment 3

19 years ago
this is html code generation, please reassign to the appropriate person in
the editor

Updated

19 years ago
Assignee: buster → akkana

Comment 4

19 years ago
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?"
(Assignee)

Comment 5

19 years ago
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?

Comment 6

19 years ago
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.
(Assignee)

Comment 7

19 years ago
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?

Comment 8

19 years ago
the charset information should be availble from the nsIDocument.  Look at
nsEditor::GetDocumentCharset.

/t
(Assignee)

Comment 9

19 years ago
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)?

Comment 10

19 years ago
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
(Assignee)

Updated

19 years ago
Status: NEW → ASSIGNED
(Assignee)

Comment 11

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
(Assignee)

Comment 12

19 years ago
Fixed for the case indicated (which does fix the Save As case mentioned at the
top of this bug).
(Reporter)

Updated

19 years ago
Status: RESOLVED → REOPENED
(Reporter)

Comment 13

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

Updated

19 years ago
Resolution: FIXED → ---
(Assignee)

Comment 14

19 years ago
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.
(Assignee)

Updated

19 years ago
Status: REOPENED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → DUPLICATE
(Assignee)

Comment 15

19 years ago
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 ***

Comment 16

19 years ago
checked for duplication with bug # 7849
(Reporter)

Updated

18 years ago
Status: RESOLVED → VERIFIED
(Reporter)

Comment 17

18 years ago
Verified as dup.
You need to log in before you can comment on or make changes to this bug.