ALT + NUM Pad operation moves the cursor point unnecessarily

VERIFIED FIXED in M14

Status

P3
critical
VERIFIED FIXED
19 years ago
11 years ago

People

(Reporter: momoi, Assigned: kinmoz)

Tracking

Trunk
x86
Other

Firefox Tracking Flags

(Not tracked)

Details

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

(Reporter)

Description

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

Updated

19 years ago
Assignee: ducarroz → beppe
QA Contact: lchiang → sujay

Comment 1

19 years ago
qa contact to sujay since this is in regular composer.
reassign to beppe.

Updated

19 years ago
Assignee: beppe → jfrancis
Target Milestone: M13

Comment 2

19 years ago
assigning to jfrancis

Updated

19 years ago
Status: NEW → ASSIGNED
(Reporter)

Comment 3

19 years ago
See also a related Bug 22205.

Updated

19 years ago
Assignee: jfrancis → brade
Status: ASSIGNED → NEW

Comment 4

19 years ago
reassign to myself to do some preliminary investigation for jfrancis

Updated

19 years ago
Status: NEW → RESOLVED
Last Resolved: 19 years ago
Resolution: --- → FIXED

Comment 5

19 years ago
I think Joe fixed this problem.
I tested it with a build from today and it now works.

Updated

19 years ago
Status: RESOLVED → VERIFIED

Comment 6

19 years ago
verified in 1/7 build.

Comment 7

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

Updated

19 years ago
Resolution: FIXED → ---

Comment 8

19 years ago
reassign to jfrancis since he's the caret guru and may know what changes affected 
this.
Assignee: brade → jfrancis
Status: REOPENED → NEW
(Reporter)

Comment 9

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

Comment 10

19 years ago
Re-assigning QA contact to marina as this is needed for Intl mail and 
composer input.
QA Contact: sujay → marina

Comment 11

19 years ago
accepting bug.  no need to hold m13 for this.  m14'ing...
Status: NEW → ASSIGNED
Target Milestone: M13 → M14
(Reporter)

Comment 12

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

Comment 13

19 years ago
Putting on PDT+ radar for beta1.
Whiteboard: [PDT+]
(Assignee)

Comment 14

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

Comment 15

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

Comment 16

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

Comment 17

19 years ago
Yes, bug 22205 is a dup of this bug.
(Assignee)

Comment 18

19 years ago
Kat,

Is this Alt-numpad key sequence neccessary for IME?

What about the concern pgunn01@ibm.net brings up above?
(Reporter)

Comment 19

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

Comment 20

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

Comment 21

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

Comment 22

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

Comment 23

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

Comment 24

19 years ago
Tag! Kin, you're it!
Assignee: jfrancis → kin
Status: ASSIGNED → NEW
(Reporter)

Comment 25

19 years ago
*** Bug 22205 has been marked as a duplicate of this bug. ***
(Reporter)

Updated

19 years ago
Blocks: 22205
(Reporter)

Updated

19 years ago
QA Contact: marina → momoi
(Assignee)

Comment 26

19 years ago
Accepting bug.
Status: NEW → ASSIGNED
(Assignee)

Updated

19 years ago
Whiteboard: [PDT+] → [PDT+] Fix expected on 02/10/2000
(Assignee)

Comment 27

19 years ago
I have a fix in hand that prevents caret movement while the alt key is down. 
Currently waiting on code review.
(Assignee)

Comment 28

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

Comment 29

19 years ago
oops forgot to mark FIXED.
Status: ASSIGNED → RESOLVED
Last Resolved: 19 years ago19 years ago
Resolution: --- → FIXED
(Reporter)

Comment 30

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