Closed Bug 22206 Opened 25 years ago Closed 25 years ago

ALT + NUM Pad operation moves the cursor point unnecessarily

Categories

(MailNews Core :: Composition, defect, P3)

Product:
MailNews Core
Component:
Composition
Platform:
x86
Other
Type:
defect

Tracking

(Not tracked)

Status:
VERIFIED FIXED

People

(Reporter: momoi, Assigned: kinmoz)

References

Details

(Whiteboard: [PDT+] Fix expected on 02/10/2000) 

** 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!
Assignee: ducarroz → beppe
QA Contact: lchiang → sujay
qa contact to sujay since this is in regular composer.
reassign to beppe.
Assignee: beppe → jfrancis
Target Milestone: M13
assigning to jfrancis
Status: NEW → ASSIGNED
See also a related Bug 22205.
Assignee: jfrancis → brade
Status: ASSIGNED → NEW
reassign to myself to do some preliminary investigation for jfrancis
Status: NEW → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
I think Joe fixed this problem.
I tested it with a build from today and it now works.
Status: RESOLVED → VERIFIED
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
Resolution: FIXED → ---
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.
Keywords: 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.
Whiteboard: [PDT+]
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 pgunn01@ibm.net brings up above?
kin, we arecurrently able to input high-ascii characters in all 3 platforms. 

I take it that pgunn01@ibm.net'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 , pgunn01@ibm.net' 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. ***
Blocks: 22205
QA Contact: marina → momoi
Accepting bug.
Status: NEW → ASSIGNED
Whiteboard: [PDT+] → [PDT+] Fix expected on 02/10/2000
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

r=brade@netscape.com,akkana@netscape.com
oops forgot to mark FIXED.
Status: ASSIGNED → RESOLVED
Closed: 25 years ago → 25 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
Product: MailNews → Core
Product: Core → MailNews Core
You need to log in before you can comment on or make changes to this bug.