** Observed with 12/17/99 Win32 M12 build ** I noticed this problem in both regular Composer and Mail Composer. We seem to have also a similar/related problem in Reply/quoted mail composition. Marina is filing the latter bug. This bug is just for new composition but it seems that the cursor point operation is currently screwed up for ALT + NUM key operation. [Under Composer and New Mail Composer] 1. Type something like, "abcdefg" 2. Insert the cursor into the spot between 'c' and 'd'. 3. now use ALT + 0234 to insert "e" with the circumflex. 4. Note that the 'e' with the circumflex was inserted between 'b' and 'c' instead!
qa contact to sujay since this is in regular composer. reassign to beppe.
assigning to jfrancis
See also a related Bug 22205.
reassign to myself to do some preliminary investigation for jfrancis
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED
I think Joe fixed this problem. I tested it with a build from today and it now works.
verified in 1/7 build.
I'm reopening this bug,because it is reemerging as a problem again.It is not possible to enter consequitively a line of non-ascii chars, you have to correct a char's position every time, cursor point is screwed up for alt+num operation. Repeat all steps that Kat suggested and you'll see the problem. It is a valid problem for Editor, Mail, ABook.
Status: VERIFIED → REOPENED
reassign to jfrancis since he's the caret guru and may know what changes affected this.
Assignee: brade → jfrancis
Status: REOPENED → NEW
This is too much of a problem to be ignored for Beta 1. A must for Beta 1. Let me add a bit more observation to what I reported originally. 1. Try to insert an ALT+NUMPad characters into the final position of an existing string of "abcd". You will see that it gets intserted into the poisition between c and d, the one before the final position. 2. Try to insert an ALT_NUMPad character into a position between, "a" and "b" in an existing "abcd" string. It gets inserted into a position between "c" and "d" as in 1. So the problem is that when Alt+Num Pad is engaged we somehow always reset the cursor position to the one before the final position (i.e. penultimate position).
Summary: ALT + NUM Pad operation moves the cursor point unnecessarily → [Beta 1] ALT + NUM Pad operation moves the cursor point unnecessarily
Re-assigning QA contact to marina as this is needed for Intl mail and composer input.
QA Contact: sujay → marina
accepting bug. no need to hold m13 for this. m14'ing...
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
Updated keyword field to reflect beta1.
Summary: [Beta 1] ALT + NUM Pad operation moves the cursor point unnecessarily → ALT + NUM Pad operation moves the cursor point unnecessarily
Putting on PDT+ radar for beta1.
This should probably be assigned to someone dealing with XUL keybindings. The problem only occurs when the numlock key is not down. The '2', '4', '6', and '8' keys, on the num pad, act as arrow keys when the numlock key is not down. What's happening here is that the XUL bindings for the arrow keys are getting triggered, even though the ALT key is down. The bindings need to be modified so that ALT arrow key is ignored. The editor never sees the keys being typed until the ALT key goes up and the OS fires off a key event.
So, kin, fixing this problem should solve Bug 22205. Should we mark the other one as a duplicate of this bug and track it when this bug is done with?
Most high-ascii characters differ from Mac to Linux to Windows, so the simple solution of disabling high-ascii input (however that can be done) would probably be best for the internet.
Yes, bug 22205 is a dup of this bug.
Kat, Is this Alt-numpad key sequence neccessary for IME? What about the concern firstname.lastname@example.org brings up above?
kin, we arecurrently able to input high-ascii characters in all 3 platforms. I take it that email@example.com's remark is simply a tonge-in-cheek statement, a bit funny, maybe, but totally inapproriate in the context of our serious efforts to fix this problem for Windows.
No, I'm totally serious. The use of alt-numpad is primarily used to generate high-ascii characters (why else would you use it), and high-ascii characters are totally nonportable because MacOS, Windows, and Unix disagree as to the contents of the upper half of the ASCII set. So it might be better to disable the alt-numpad (if possible) rather than fix it. Maybe MSDN has some code to do so?
We have mail standard charsets to deal with the issues like the one you're talking about. For example, for Larin 1 languages, Mozilla sends outmsgs using ISO-8859-1 charset. All reputable mailers would know how to map this charset to their own OS encoding, ISO-8859-1 ionUnix, Windows-1252 on Windows, and MacRoman on Macintosh. It's been working like this since the days of Navigator 1.x. I'm totally confused by the intent of your suggestion.
Note also that we promote sending Latin 1 messages only with the Internet standard Latin 1 charset, i.e. ISO-8859-1. I'm sorry but your comments are simply off the mark.
Hi , firstname.lastname@example.org' I re-read your comments and maybe there is one respect in which they address an important issue. That is, it would be best for users not to use the high-ascii characters which are not available in other platforms. ISO-8859-1 charset is the lowest common denominator. The characters in that charset are available on all platforms though mapped to different code points sometimes. This is why you don't see anything other than ISO-8859-1 as the mail send charset in our Mail Composer menu. That is how we discourage users from inputting high-ascii characters available only on Windows platform. But the ALT+NUMPad operation must be working on Windows for inputting other high-ASCII characters in ISO-8859-1 charset otherwise communication in most European languages will be impossible Please understand that we are addressing your concerns in other ways and we hope you'll find the final product to be reflective of inter-operability concerns.
Tag! Kin, you're it!
Assignee: jfrancis → kin
Status: ASSIGNED → NEW
*** Bug 22205 has been marked as a duplicate of this bug. ***
Status: NEW → ASSIGNED
I have a fix in hand that prevents caret movement while the alt key is down. Currently waiting on code review.
Fix checked in. Should appear in the 02/10/2000 builds. Modified all keybindings for up, down, left, right, home, end, pgUp, and pgDown so that they are not triggered if the Alt key is down. mozilla/xpfe/global/resources/content/editorBindings.xul revision 1.6 mozilla/xpfe/global/resources/content/browserBindings.xul revision 1.7 mozilla/xpfe/global/resources/content/inputBindings.xul revision 1.11 mozilla/xpfe/global/resources/content/textAreaBindings.xul revision 1.4 mozilla/xpfe/global/resources/content/win/platformInputBindings.xul revision 1.3 mozilla/xpfe/global/resources/skin/htmlBindings.xml revision 1.4 mozilla/xpfe/global/resources/skin/win/platformHTMLBindings.xml revision 1.3 email@example.com,firstname.lastname@example.org
oops forgot to mark FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago → 19 years ago
Resolution: --- → FIXED
** Checked with 2/17/2000 Win32 build ** With the above build, ALT+NUMPad actions do not lead to erratic cursor behavior. I can now input accented Latin 1 characters without any problem either on a new line, or at an insertion point in the middle of an exsiting text. The latter problem was reported in Bug 22205. All of this without locking NumPad, which is what users expect under EN keyboard. All these problems seem to have gone away with this fix. Marking the fix verified.
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.