Closed Bug 25280 Opened 26 years ago Closed 26 years ago

Unable to input any non-ascii chars into the Subject field

Categories

(MailNews Core :: Internationalization, defect, P4)

Product:
MailNews Core
Component:
Internationalization
Platform:
x86
Windows NT
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: marina, Assigned: hyatt)

References

Details

(Whiteboard: [PDT+])

This is a big regression compare to M13 Steps to reproduce: -open new mail; -using Alt+Num pad try to input non-ascii chars: //note: there is no input happening ***** observed in 2000-01-27-08 win build ***** (in the "To" field it is possible to enter one chars but not several consequitively)
How about text fields in browser like forms?
The behavior in browser forms is similar to the one in "To" field, meaning i can input only one non-ascii chars consequitively.In the Subject field of the messenger i'mnot able to do so at all.
I think this is a generic text widget problem, reassign to editor group.
Assignee: nhotta → beppe
Using today's win32 build (2000012708), I cannot reproduce the problem. I can input á (alt+numkey 0225) multiple times in both subject and address fields. I am using NT4 US sp3.
Can an e-acute be entered on Mac?
I am able to reproduce this problem on today;s Win32 build. Apparently, after you do one ALT+NUMPad entry, the focus is lost sometimes, and thereafter no input seems possible until the cursor is placed again into the field. Apparently we shipped M13 with a limited version of this problem. I can reproduce some of the problem with M13 Win32 build. It seems that this is related to Bug 22206 which is assigned to jfrancis@netscape.com. There we reported shifting of the cursor away from the real insertion point every time ALT+NUMPad input is made.
On my local Mac debug build, yes I can enter option+tilda+a.
reassigning this one to ftang
Assignee: beppe → ftang
I think this is beta1 material -- So marked.
Keywords: beta1
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
Is this still happening after the re-spin?
With Win32 2000012715 (3rd build of the day), I can input one ALT+NUMPad character under NT4-J, but beyond that still seems to be impossible. The Editor function is now back but in the Edit field, too, I can input at most 2 ALT+NUMPad characters. After that, I have to input some ASCII characters and hope I can use ALT+NUMPad again. This isn't always successful, however.
I can confirm the same results with the latest build.
It seems a ALT key problem again. I think hyatt and saari still tracking the ALT keypress to do something. Reassign to hyatt.
Assignee: ftang → hyatt
QA assignment to marina.
QA Contact: momoi → marina
I don't eat events until the alt key comes up. This isn't my bug AFAIK.
Assignee: hyatt → ftang
hyatt- can you explain what do you mean "I don't eat events until the alt key comes up." ? Are you tracking the KeyUp of Alt key ?
Status: NEW → ASSIGNED
Target Milestone: M14
OK, the problem is not with ALT but with those num pad. I have no problem to input if the Num Lock is on.
What happen is the following, when user type Alt+213, the following event get send KeyDown Alt KeyDown VK_DOWN IsAlt KeyPress VK_DOWN IsALT KeyUp VK_DOWN IsAlt KeyDown VK_End IsAlt KeyPress VK_End IsALT KeyUp VK_End IsAlt KeyDown VK_PageUP IsAlt KeyPress VK_PageUP IsALT KeyUp VK_PageUP IsAlt KeyUp Alt KeyPress (the real character) Some code somehow didn't check the IsAlt flag in the event and treat it as normal Down, PageDown and End key. Reassign to akkana. Akkana, I don't know who's code intercept those key event. Can you help to look at it ?
Assignee: ftang → akkana
Status: ASSIGNED → NEW
I don't know anything about the Windows key event handler; I've only looked at the linux one. What code remaps the alt+keypad keys? Is that an IM thing? It doesn't sound like a standard us-en input thing.
Assignee: akkana → ftang
No. The code which caused problem is not in window code. The problme is there are some event handler which watch for VK_HOME, VK_UP, VK_PAGEUP,VK_LEFT, VK_RIGHT, VK_END, VK_DOWN, VK_PAGEDOWN and do some action. However, in window, people can use ALT + these key to input character code value. For example, press ALT and '6' (left) and '5' will generate character code 'A' . However, since some key event handler tracking these key and peroform action (for exampel- move cursor left, right, etc ) without checking ALT is down or not. The keyevent handler should not do these action when the ALT key is down (when isAlt is true). The problem is in some cross-platform event handler- maybe editor or also other places. Please fix the event handling in editor. Thanks.
Assignee: ftang → akkana
I think I found the problem. The problem is in key binding. When the ALT+1 (Num Pad 1) the nsXBLEventHandler::ExecuteHandler(const nsString& aEventName, nsIDOMEvent* aEvent) send a command 'cmd_endLine' to NS_IMETHODIMP nsEditorController::DoCommand(const PRUnichar *aCommand) even when the ALT is down. This happen to all the num pad key with ALT. hyatt- please understand that alt+ these num pad key can be used to input character code. This is a very handy feature for non English user. For example- ALT+65 is hex 41 which will generate 'A'. However, because additional editor command get dispatch, it cause the cursor move or shift focus to other text field. Please change the key binding so these key (HOME,END,PGUP,PGDOWN,LEFT,RIGHT, UP,DOWN,INS) won't cause these command when the ALT key is down. I think you should either change the xul file (inputBinding.xul ?) so it only file the command when the alt key is not down or make the default behavior check the isAlt key. I found the following file incldue this command http://lxr.mozilla.org/seamonkey/search?string=cmd_endLine It seems the default xul keybinding is written by hyatt and the editor one is written by mjudge. Reassign this to hyatt first for the default xul keybinding files. mjudge, please work with hyatt and change the editor xul keybinding file which used by window for this also.
Assignee: akkana → hyatt
Depends on: 26404
Frank, you might want to try adding alt="false" to the bindings for the keys you're having problems with in xpfe/global/resources/skin/html/htmlBindings.xml and see if it fixes the problem.
Yeah, I just added that same comment to the bug filed against mjudge. Adding alt="false" should solve the problem.
Status: NEW → ASSIGNED
I will try that. Is this the only file I should change ? I am not sure how many xul keybinding file is there and which is used by what
I talk to mjudget and add alt="false" to htmlBindings.xml and inputBinding.xul but it still does not work. Am I change the right file ? or it is caused by bug 26261 ?
P4, relative to hyatt's other open PDT+ bugs
Priority: P3 → P4
There's a bug in the XBL Event handler. It doesn't look for false. I have a fix in hand. Will check in when tree opens.
Fix checked in. You'll still need to make sure you've put alt="false" on the key bindings though.
Status: ASSIGNED → RESOLVED
Closed: 26 years ago
Resolution: --- → FIXED
marina is on vacation --> momoi for verification.
QA Contact: marina → momoi
** Checked with 2/18/2000 Win32 build ** With the above build, we can now input any number of ALT+NumPad characters consecutively in header fields or text edit fields in Mail and elsewhere. Marking this 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.