432002 - |Bug 429219 – Ctrl+1, Ctrl+2, etc, regression (on fr(-FR) keyboard), after bug 359638| follow-up for SeaMonkey

Status: NEW

(SeaMonkey :: General, defect)

Description

[Serge Gautherie (:sgautherie)]

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9pre) Gecko/2008050302 SeaMonkey/2.0a1pre] (nightly) (W2Ksp4)

Initially, I filed bug 429219 about SeaMonkey,
but it was morphed to a Firefox "only/mainly" bug,
then here I go again !

Bug 429219 (Core part) did fix most of the issue for SeaMonkey too :-)
But there are still some inconsistent behaviors :-(

(and it's not obvious to me where/how to port/fix the </browser/*> part.)

***

2 issues (compared to (current/new) Firefox behavior):

1a) Ctrl + Shift + (KeyPad)"+"
Works in SM ... but doesn't in FF.
Ctrl + Shift + (KeyPad)"-" doesn't work in either applications.

1b) CapsLock + Ctrl + Shift + (KeyPad)"+"
Same as 1a.

1*)
This seems rather unexpected, the two applications being Gecko/Toolkit based.
Yet, I'm not sure what to suggest:
*NotePad++ v4.8.2 behaves as FF.
*OpenOffice v2.4 behaves as SM.
:-/

2a) Ctrl + (alpha-num)"-"
Acts as Ctrl+6 (= ChatZilla) in SM ... but as Ctrl+"-" (= Zoom Out) in FF.

2b) CapsLock + Ctrl + Shift + (alpha-num)"-"
(Acts as Ctrl+"-" (= Zoom Out) in SM too :-))

2*)
This was discussed in bug 429219 comment 30, bug 429219 comment 32, bug 429219 comment 42.
Then, this was +/- expected,
yet, I think a FF-like behavior would be better:
I guess that Zoom-Out is more often used than Start-ChatZilla.

Comment 1

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
> 1a) Ctrl + Shift + (KeyPad)"+"
> Works in SM ... but doesn't in FF.
> Ctrl + Shift + (KeyPad)"-" doesn't work in either applications.
> 
> 1b) CapsLock + Ctrl + Shift + (KeyPad)"+"
> Same as 1a.
> 
> 1*)
> This seems rather unexpected, the two applications being Gecko/Toolkit based.
> Yet, I'm not sure what to suggest:
> *NotePad++ v4.8.2 behaves as FF.
> *OpenOffice v2.4 behaves as SM.
> :-/

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.15pre) Gecko/2008050303 BonEcho/2.0.0.15pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.13) Gecko/20080313 SeaMonkey/1.1.9] (release) (W2Ksp4)

On Gecko/v1.8.1.x branch, all four combinations worked.
Then, this is a Core regression:
*SM v2 is 25% broken.
*FF v3 is 50% broken.

Despite being different than NotePad++ and OpenOffice behaviors,
I think that if we can restore FFv2.0/SMv1.1 behavior, without braking anything else, that would be wanted.


[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515 SeaMonkey/1.5a] (nightly) (W2Ksp4)

SMv1.5a already behaved as current SMv2.0,
then this part regressed (long) before bug 359638.

Comment 2

[Serge Gautherie (:sgautherie)]

(In reply to comment #0)
> 2a) Ctrl + (alpha-num)"-"
> Acts as Ctrl+6 (= ChatZilla) in SM ... but as Ctrl+"-" (= Zoom Out) in FF.
> 
> 2b) CapsLock + Ctrl + Shift + (alpha-num)"-"
> (Acts as Ctrl+"-" (= Zoom Out) in SM too :-))
> 
> 2*)
> This was discussed in bug 429219 comment 30, bug 429219 comment 32, bug 429219
> comment 42.
> Then, this was +/- expected,
> yet, I think a FF-like behavior would be better:
> I guess that Zoom-Out is more often used than Start-ChatZilla.

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.15pre)
Gecko/2008050303 BonEcho/2.0.0.15pre] (nightly) (W2Ksp4)
[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.13) Gecko/20080313
SeaMonkey/1.1.9] (release) (W2Ksp4)

On Gecko/v1.8.1.x branch, all four combinations worked as Ctrl+6.
Then, the new behavior is an improvement :-)

[Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a5pre) Gecko/20070515
SeaMonkey/1.5a] (nightly) (W2Ksp4)

[CapsLock +] Ctrl + "-" acted as Ctrl+6.
[CapsLock +] Ctrl + Shift + "-" did not work.
Then, this seemed to have been "WorkInProgress" between the old and the new behavior of this part.

*****

Bottom-line:
*Issue 1* seems to be a Core regression (to fix), as bug 429219 was.
*Issue 2a seems to be SeaMonkey specific (follow-up).

Comment 3

[Mike Beltzner [:beltzner, not reading bugmail]]

If this is SM only, can we fix it on branch and not block gecko1.9 on it?

Comment 4

[:Gavin Sharp [email: [e-mail]]]

This fix needs to happen in SeaMonkey code, so I don't see why this needs to block Gecko 1.9.

Comment 5

[Serge Gautherie (:sgautherie)]

(In reply to comment #1)
> On Gecko/v1.8.1.x branch, all four combinations worked.
> Then, this is a Core regression:
> *FF v3 is 50% broken.

(In reply to comment #4)
> This fix needs to happen in SeaMonkey code, so I don't see why this needs to
> block Gecko 1.9.

Are you saying that the new behavior of Firefox *is* wanted as it is right now ?
Otherwise, SeaMonkey code will not fix Firefox...

Comment 6

[:Gavin Sharp [email: [e-mail]]]

Your comments are too difficult to read, so I was making my comment based on the summary, "follow-up for SeaMonkey". If you're actually reporting a problem that applies to both Firefox and SeaMonkey, you should probably pick a better summary and provide a concise description of the problem. If so, I apologize for morphing the bug incorrectly.

Comment 7

[Serge Gautherie (:sgautherie)]

(In reply to comment #6)
> Your comments are too difficult to read, so I was making my comment based on

(I'm doing what I can: the subject is not easy.)

> the summary, "follow-up for SeaMonkey". If you're actually reporting a problem
> that applies to both Firefox and SeaMonkey, you should probably pick a better

Ah, well, that's the second bug in a raw where I try to report a SeaMonkey regression then end up finding some Core regression :-|

> summary and provide a concise description of the problem. If so, I apologize
> for morphing the bug incorrectly.

I thought
{{
Bottom-line:
*Issue 1* seems to be a Core regression (to fix), as bug 429219 was.
*Issue 2a seems to be SeaMonkey specific (follow-up).
}}
would be clear enough, but may be not :-/

Then, yes, the new goal of this bug is to fix case 1.
I'll file (yet) another follow-up if case 2 is still there after that.

Comment 8

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

Issue 1 is "[CapsLock +] Ctrl + "-" acted as Ctrl+6"?

If so, we designed so. Current keypress event's charCode prefers CapsLock state and Shift key state. So, CapsLock + '-' sends '6'. If without CapsLock, it sends '-'.

Comment 9

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

There are two ideas of accel key handling:

1. An accel key combination is some modifier keys and a "key".
2. An accel key combination is some modifier keys and a "char" that comes from the key.

Now we are using 2nd way on latest trunk. Because "key" approach is too difficult approach for i18n. E.g., an key may have two (or more) meaning on some keyboard layout like '-' key of French keyboard layout. Then, we need to decide which meaning is selected by the users. But it's unresolvable issue. So, the "char" approach is simpler and better approach, I think. The char depends on Shift key and CapsLock state. Therefore the acutal key combination is different between unCapsLocked time and CapsLocked time.

If you think we should not prefer CapsLock state with Ctrl key is pressed, we may be able to do it easy. But I want to listen the other French keyboard layout user's comments. The CapsLock state preferred approach (current) and ignoring the state approach, which approach is natural behavior for the users.

Comment 10

[Serge Gautherie (:sgautherie)]

(In reply to comment #8)
> Issue 1 is "[CapsLock +] Ctrl + "-" acted as Ctrl+6"?

No, issue 1 is comment 1: (KeyPad)"+"/"-" handling regression(s).

> If so, we designed so. Current keypress event's charCode prefers CapsLock state
> and Shift key state. So, CapsLock + '-' sends '6'. If without CapsLock, it
> sends '-'.

Yes, this behavior is bug 429219 and would be more related to issue 2;
but let's forget this for the time being.

***

(In reply to comment #9)
> But I want to listen the other French keyboard

I guess the KeyPad is the same whatever the ("latin") keyboard layout ?

> layout user's comments. The CapsLock state preferred approach (current) and
> ignoring the state approach, which approach is natural behavior for the users.

I'm not sure, but I would think "/", "*", "-", "+" on the KeyPad should always work ... at least, that's what they did in the previous release.

Yet, if the new Firefox behavior is indeed wanted,
then issue 1, as issue 2 is, would be a SeaMonkey only inconsistency/follow-up.

Comment 11

[Serge Gautherie (:sgautherie)]

(In reply to comment #10)
> (In reply to comment #8)
> > Issue 1 is "[CapsLock +] Ctrl + "-" acted as Ctrl+6"?
> 
> No, issue 1 is comment 1: (KeyPad)"+"/"-" handling regression(s).

Maybe I wasn't explicit enough:

I'm speaking of the _Numeric_ Keypad:
<http://en.wikipedia.org/wiki/Numeric_keypad>

Comment 12

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #10)
> (In reply to comment #8)
> > Issue 1 is "[CapsLock +] Ctrl + "-" acted as Ctrl+6"?
> 
> No, issue 1 is comment 1: (KeyPad)"+"/"-" handling regression(s).

Did you mean that Ctrl+Shift+'-' in Numpad and Ctrl+Shift+'+' in Numpad should work as Ctrl+'-' and Ctrl+'+'?? If so, this bug is INVALID. Ctrl+Shift+'-' and Ctrl+'-' are different key combination. We should not ignore the Shift key in such case.

Please forget other behaviors (e.g., OOo and Fx2). We should determine what behavior is best for us.

Comment 13

[Mike Beltzner [:beltzner, not reading bugmail]]

I'll let Masayuki renom, but for now, this won't block and might be INVALID.

Comment 14

[Tony Mechelynck [:tonymec]]

Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050501 SeaMonkey/2.0a1pre

Don't know if the following is useful, but just in case...

My Belgian keyboard is similar but not identical to a French keyboard: it has AZERTY layout but the + and - keys are as follows:

On the top row, two steps right of the zero: unshifted -, shifted _
On the bottom row, at far right just left of RightShift: unshifted =, shifted +

On both the main keyboard and the numeric keypad, Ctrl++ works with or without Shift; Ctrl+- works only without Shift.

About other keys: 0 (zero) is Shift+à (a-grave); Ctrl+à and Ctrl+Shift+à both zoom to default size, but on the numeric keypad Ctrl+0 only restores zoom if used without Shift.

Without Ctrl (when in this textarea): both NumPad- and Shift+NumPad- instert a dash; both NumPad+ and Shift+NumPad+ insert a plus; NumPad0 inserts a zero but Shift+NumPad0 pastes the clipboard.

Comment 15

[Tony Mechelynck [:tonymec]]

P.S. I am using NumLock on, of course.

Comment 16

[Masayuki Nakano [:masayuki] (he/him)(JST, +0900)]

(In reply to comment #14)
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050501
> SeaMonkey/2.0a1pre

Please test with Fx. SeaMonkey doesn't finish the front end part works.

> On the top row, two steps right of the zero: unshifted -, shifted _
> On the bottom row, at far right just left of RightShift: unshifted =, shifted +
> 
> On both the main keyboard and the numeric keypad, Ctrl++ works with or without
> Shift; Ctrl+- works only without Shift.

On numpad, Ctrl+Shift++ should not work. And I cannot reproduce the "bug".

And Ctrl+= should work as Ctrl++ on *English* Fx too. Because '=' and '+' of US keyboard layout are mapped to same key. So, it's a localized for the US keyboard layout on English Fx. It's not a bug.

> About other keys: 0 (zero) is Shift+à (a-grave); Ctrl+à and Ctrl+Shift+à
> both zoom to default size, but on the numeric keypad Ctrl+0 only restores zoom
> if used without Shift.

We appended a special behavior for AZERTY keyboard layout. Ctrl+Num can be accessed without CapsLock/Shift key if the Ctrl+unshifted key doesn't match to any commands. Therefore, you can access to ZoonReset with Ctrl+à.

Comment 17

[Serge Gautherie (:sgautherie)]

(In reply to comment #12)
> Did you mean that Ctrl+Shift+'-' in Numpad and Ctrl+Shift+'+' in Numpad should

Yes, this was my (issue 1) question.
I wasn't sure if it was a wanted change or a regression from FFv2.
You say it's wanted: fine with me :-)

> work as Ctrl+'-' and Ctrl+'+'?? If so, this bug is INVALID.

Not fully invalid:
now, I know that issue 1 is SeaMonkey specific too ;->

*****

New short bug description:

In SeaMonkey,

1)
Ctrl + Shift + (NumPad)'+', with/without CapsLock, should not act as Ctrl + '+' (= Zoom In) anymore.

2)
Ctrl + (alpha-num)"-" should not act as Ctrl + 6 (= ChatZilla) anymore.

Comment 18

[Serge Gautherie (:sgautherie)]

(In reply to comment #14)
> Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9pre) Gecko/2008050501
> SeaMonkey/2.0a1pre
> 
> Don't know if the following is useful, but just in case...

(Let's fix the two reported issues on fr-FR layout,
then you can check again if there are remaining "issues" on the fr-BE layout. ;-))

Comment 19

[Ian Neal]

Not something we need to get fixed for SM2.0a1 but will take a fix if there is one.

Comment 20

[Robert Kaiser]

I can't parse too well what's actually the really left bug here, but I don't see anything in the description we should push out a release for, so not blocking on this one. At best, this is a polish issue, at worst, it's a WONTFIX.