Closed Bug 5063 Opened 26 years ago Closed 25 years ago

[I18N][ENDER] Cannot copy/paste Japanese strings properly into the subject header field

Categories

(MailNews Core :: Internationalization, defect, P2)

Tracking

(Not tracked)

VERIFIED WORKSFORME

People

(Reporter: momoi, Assigned: buster)

References

Details

(Whiteboard: DEPEND - Intl - QA BLOCKER - ok for future M build)

** Observed with 4/13/99 Win 32 build ** We are not able to input Japanese into the subject field either via the Windows IME (see Bug #5061), or by copy/pasting strings from another browser page (e.g. via Communicator 4.5x). We can actually copy/paste some strings but they don't display as Japanese. Neither does it show up as Japanese once received.
Target Milestone: M5
This is needed for M5 (to support MIME encode for Japanese). Bob, who should I assgin this, xpfe?
I tried this on my machine (WinNT4 US). I the debugger, a pasted Shift_JIS text (hex: 8B4382C9...) was converted to unicode (hex: 008B0043008200C9). So the conversion is wrong (or missing). The message composer uses a class nsIDOMHTMLInputElement for the subject field. This class may need to convert from Shift_JIS to unicode. But I am not clear about how to do that. The class needs a charset info or has to assume it as the system charset in order to pick up a from charset for the conversion. Since we're now unicode base, we could allow the user to input multiple languages (e.g. French + Japanese). Do we have spec for this? Regarding the dom class, I found that the parent class nsIDOMHTMLElement has GetLang/SetLang. I haven't looked at the implementation (not sure what string to pass) but the message compose may call this. Then we need to convert charset to lang...
Adding vidur@netscape.com (found in cvs log of nsIDOMHTMLInputElement ), kostello@netscape.com to cc. Is nsIDOMHTMLInputElement based on Ender? If so, the paste problem may be related to the bug#4388.
nsIDOMHTMLInputElement is just an interface implemented by the nsHTMLInputElement class (found in mozilla/layout/html/content/src). Eric Pollmann is the owner of that class and other things form related.
Assignee: nhotta → pollmann
Reassigning to Eric based upon Vidur's comment. This is blocking the M5 deliverable for sending Japanese email.
Assignee: pollmann → pierre
As I understand it we won't be supporting this with native widgets, but only through GFX/Ender. Reassigning to Pierre.
Assignee: pierre → ftang
i18n issue: reassigned to ftang
Status: NEW → RESOLVED
Closed: 26 years ago
Resolution: --- → LATER
We won't support asian languages before Ender is used in GFX-rendered widgets. Closed as Later.
Status: RESOLVED → REOPENED
Please do not close this kind of bug. We need this before we ship 5.0. We cannot close this bug. We do understand we need Ender to support this. This bug should be closed the date we switch the <TEXTAREA> and <INPUT type=text> to ender. Reopen. When (which M build?) do we plan to switch <TEXTAREA>, <INPUT type=text>, and the file name field in <INPUT type=file> to ENDER ?
Resolution: LATER → ---
Assignee: ftang → pierre
Status: REOPENED → NEW
reassign to peirre. Pierre, please leave it open till we switch to ender.
Status: NEW → ASSIGNED
Target Milestone: M5
OS: Windows NT → All
Priority: P3 → P2
Hardware: PC → All
Summary: Cannot copy/paste Japanese strings properly into the subject header field → [I18N/ENDER] Cannot copy/paste Japanese strings properly into the subject header field
Target Milestone: M9
Whiteboard: QA BLOCKER
Adding to QA Blocker radar.
Summary: [I18N/ENDER] Cannot copy/paste Japanese strings properly into the subject header field → [I18N][ENDER] Cannot copy/paste Japanese strings properly into the subject header field
Whiteboard: QA BLOCKER → QA BLOCKER - ok for future M build
Whiteboard: QA BLOCKER - ok for future M build → DEPEND - Intl - QA BLOCKER - ok for future M build
Blocks: 7228
Moving to M15 all the bugs that have a dependancy on GFX widgets and/or Ender.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago26 years ago
Resolution: --- → DUPLICATE
Should be fixed by Ender-based text widget. See bug #6262. *** This bug has been marked as a duplicate of 6262 ***
Status: RESOLVED → VERIFIED
Verified Dup of Bug 6262
Status: VERIFIED → REOPENED
Resolution: DUPLICATE → ---
Jay, please look at the QA Contact field to see if this has been assigned for you to verify. It's not clear if this is a duplicate of Bug 6262. There could be some other factor other than just Ender widget use. I tried a new Ender pref but the copy/paste failed. I'm re-opening it for now.
Status: REOPENED → ASSIGNED
Blocks: 12907
Assignee: pierre → buster
Status: ASSIGNED → NEW
Reassigned to buster whos is now taking care of gfx text widgets.
Kat--Can you check if this is still broken? If so, can you clarify if both copy and paste are broken or just paste? To do this you might try copying within Apprunner text widget and pasting into 4.5 (as well as copying in 4.5 and pasting into 5.0 which I think you did try). Thanks!
Kathy, as of 10/11/99's Win32 M11 build, the following seem to be true: 1. Inter-application copy/paste of non-ASCII strings is generally broken. I thought akkana told me that we need to have nsclipboard implemneted to solve some of the inter-application problems. 2. Intra-application copy/paste is generally working, but there is one glaring bug. Let me describe this bug now. ** Intra-application copy/cut and paste bugs for non-ASCII strings ** Copy/Cut and paste of non-ASCII strings works: a) within the same text area (e.g. within the same mail body text) b) from text field to text area (e.g. from Mail subject header to body text) Copy/Cut and paste of non-ASCII strings does not work: c) within the same text field (e.g. within Subject or other mail header fields.) d) from text area to text field (e.g. from mail body text to Subject field) In all cases of failure, you see "dots" instead of real characters. ------- akkana, I thought that there is already a bug for inter-application copy/cut and paste. Can you supply the bug number?
Blocks: 16127
No longer blocks: 16127
Blocks: 19423
does this work yet?
I believe that issues covered in this bugs are convered separately in other bugs and most of them have been already fixed. Whatever remains is tracked in other bugs and there is no need to keep this bug open. Marking it resolved/worksforme and then verified.
Status: NEW → RESOLVED
Closed: 26 years ago25 years ago
Resolution: --- → WORKSFORME
Marking the fix verified.
Status: RESOLVED → VERIFIED
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.