Open Bug 198233 Opened 21 years ago Updated 2 years ago

Ctrl+NumPad 0 does not restore Text Zoom to 100% if NumLock is off

Categories

(Core :: DOM: UI Events & Focus Handling, defect)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Platform:
x86
All
Type:
defect

Tracking

()

People

(Reporter: bugzillamozilla, Unassigned)

References

Details

(Keywords: helpwanted)

Attachments

(1 file, 2 obsolete files)

WIP
4.19 KB, patch
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3) Gecko/20030312

The fix for Bug 69565 introduced this (yet undocumented) keyboard shortcut into
Mozilla.

The shortcut works fine on current Mozilla builds for Linux, OS/2 and Mac OS X,
but it is broken on Windows (although Ctrl + non-NumPad 0 does work).

Reproducible: Always

Steps to Reproduce:
1. Press Ctrl++ or Ctrl+- to change the Text Zoom
2. Press Ctrl+NumPad 0 to restore the text to its original size (100%)


Actual Results:  
Nothing happens.

Expected Results:  
The text should be restored to 100%

This bug happens with 1.2.1, throughout the 1.3 branch as well as with 1.4a
(20030318)
OS: Windows 2000 → All
Linux & OS/2 are not broken. all->not
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: All → Windows 2000
Actually, on OS/2 it is *partly* broken - the NumLock has to be on in order for
this shortcut to work...

BTW, aren't keyboard shortcuts supposed to be implemented using scan-codes
rather than characters?

Prog.
I can NOT reset zoom to 100% by hitting "ctrl+numeric keypad 0" on Linux.
That was why i changed OS: to ALL. Trying again.

Current trunk CVS; Linux.
OS: Windows 2000 → All
R, I didn't see your change, thinking only the original report was broken, as
you failed to confirm when you changed. On Linux Mandrake 9.0 KDE 2003031714 it
works with NUM on, and I didn't try it with NUM off, same as OS/2 2003031712 as
described on comment 2. I never use any PC with NUM off.
Yet more confusion:

Both Ctrl+NumPad 0 and Ctrl+0 are broken on the official Mozilla 1.3-final for
BeOS (downloaded from mozilla.org)
Oddly enough, both shortcuts work perfectly on Sergei Dolgov's Mozilla 1.3b
(20030216) variant (aka Stripzilla; downloaded from BeShare P2P network)

Prog.
Confirmed with Linux RH 8.0 and 1.3-final. Exactly the same case as with OS/2 -
you can't reset zoom if NumLock is off.

Prog.
Correction: you can't reset zoom using Ctrl+NumPad 0 if NumLock is off.
On W98 in 1.4rc2 you can't switch among windows with numpad either. Ctrl+NUM0,
Ctrl+NUM1, Ctrl+NUM2, Ctrl+NUM4, Ctrl+NUM5 & Ctrl+NUM6 all do nothing, whether
NUM is on or off. 
*** Bug 216710 has been marked as a duplicate of this bug. ***
With NumLock off the number pad keys actually generate cursor keycodes so 0 is
Insert and Ctrl+Num0 will paste (windows compatibility shortcut).

With NumLock on the number pad keys generate VK_NUMPAD keycodes. Windows will
translate these to ASCII numbers, but only if they are unmodified.

We could manually translate Ctrl+ and Shift+ keycodes to ASCII numbers but we'd
have to avoid Alt+ because they're used for extended character generation.
Keywords: helpwanted
CC'ing Blake Ross and Gavin Sharp since they fixed bug 174854.
Flags: blocking-aviary1.0PR?
No, bug 256683 is specifically for help viewer. They just don't have that
shortcut key hooked up at all. This is about the Numpad 0 not returning the same
keycode as the regular 0. See comment 10.
would take a patch for this but won't hold.  renominate if a patch appears
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-
We should make this ctrl+= and not ctrl++. That's thre real behavior, at least
on windows, and it should clear up the confusion about the number pad. Blake
said he was going to change that with his recent menu changes for this feature. 
Simple switch, and it seems like this is already in the help documentation
(they have "Ctrl+= (plus sign)" listed as the shortcut).
Attachment #157196 - Flags: review?(bugs) → review?(firefox)
Ctrl+= doesn't work for example Finnish or German keyboard. On Finnish keyboard
= is on top of 0 and + is unshifted next to 0. Ctrl++ works for all keyboards
I've tested. Having the shortcut listed as Ctrl+= would confuse a lot of people
with non-us keyboards.
(In reply to comment #15)
> We should make this ctrl+= and not ctrl++. That's thre real behavior, at least
> on windows, and it should clear up the confusion about the number pad. Blake
> said he was going to change that with his recent menu changes for this
> feature. 

With all due respect, this doesn't make logical sense.  Ctrl+- is effectively
"minusing" (decreasing) the size of the text, while Ctrl++ is effectively
"plussing" (increasing) the size of the text.  Ctrl+= doesn't make sense in this
manner.

Now, if you're going to argue that that logic is hair-brained when one realizes
that "+" is only an unmodified key on the Numpad (not used so much, esp. on
keyboards) but not on the main keyboard (probably used more, esp. since most
other shortcuts are for letters, which are in the main keyboard), then you have
a point.  If you really it's a good idea to emphasize = over +, do what you want.

Is this bug for Seamonkey or Firefox?  The bug is in the Seamonkey component,
but the patch is for Firefox.  If you're fixing for Seamonkey, please patch
Seamonkey.
Attachment #157196 - Attachment description: change default from ctrl++ to ctrl+= → change default from ctrl++ to ctrl+= (aviary)
All these patches do is change the default accesskay, so the menu shows
"Ctrl+=". These patches do not turn off Ctrl++.

Both of those patches apply to trunk for FF and Seamonkey respectively.
(In reply to Asa Dotzler, comment #15)
> We should make this ctrl+= and not ctrl++. That's thre real behavior, at least
> on windows, and it should clear up the confusion about the number pad. Blake
> said he was going to change that with his recent menu changes for this feature. 

We really shouldn't. I fully agree with Jeff Walden that +/- have a sense of
bigger/smaller, while =/- do not. Instead of moving the goal posts, how about
fixing this bug? A reminder: "Ctrl+NumPad 0 does not restore Text Zoom to 100%".

Prog.
(In reply to comment #20)
> All these patches do is change the default accesskay, so the menu shows
> "Ctrl+=". These patches do not turn off Ctrl++.

Yes, and that's not good. Ctrl+= doesn't work for all keyboards. I also fully
agree that +/- is meaningful while =/- isn't.

Ere,
I understand your opposition to the switch, I just made the patch in response to
Asa's comment. I also noted that, with that patch, people using keyboards that
don't work with Ctrl+= would still be able to use Ctrl++.

I agree that this is not the best solution, but it is the easiest solution. If
someone could implement the solution mentioned by Neil in comment 10, we'd be
much better off.
Well, I believe we could special case at least ctrl-numpad keys (wouldn't be the
first special case at least for Windows' keyboard handling). I'd rather go that
way although I still don't really like translating numpad 0 to 0 when numlock
isn't on.

I can try that on Windows, any takers for other platforms?
I tried but couldn't find a way to see when numpad 0 is pressed and numlock is
off. Windows returns VK_INSERT, which is indistinguishable from the normal
insert key. 
This is a pretty important issue for us with European "numbers above" keyboards.

Basically, if the user wants to reset the text, he'll try to pull off Ctrl+0.
Here's the problem, on French/Belgian keyboards (those are the ones I know of),
to make a 0 (or any other number) you need to Shift the key (for example, on my
keyboard, Shift+à = 0), if you get what I mean. This lead to me initially trying
to Ctrl+Shift+à, which failed. Ctrl+à works, and the problem is obvious.

It would really be useful if the Numpad 0 worked, since it's a very accessible
key, and doesn't require the additional thought process of guessing whether you
need to Shift a key or not.

Requesting blocking-aviary1.0, this is a real usability issue for users with
AZERTY keyboards.
Flags: blocking-aviary1.0?
Comment on attachment 157196 [details] [diff] [review]
change default from ctrl++ to ctrl+= (aviary)

Wrong bug, and wrong change (see comment 17).
Attachment #157196 - Attachment is obsolete: true
Attachment #157196 - Flags: review?(firefox)
Comment on attachment 157206 [details] [diff] [review]
change default from ctrl++ to ctrl+= (moz1.7)

Same here.
Attachment #157206 - Attachment is obsolete: true
sounds like aaronl might not get to this for firefox 1.0.  renominate if a patch
becomes available.
Flags: blocking-aviary1.0? → blocking-aviary1.0-
*** Bug 258448 has been marked as a duplicate of this bug. ***
*** Bug 262896 has been marked as a duplicate of this bug. ***
*** Bug 283905 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary1.1?
I just discovered that this shortcut does work in recent builds for Windows when
NumLock is On (just like it always did in Linux and OS/2). Changing summary
accordingly.

cusser.bugs@cusser.net, please read comment #29 before setting the blocking
flag. This bug has no working patch.

Prog.
Flags: blocking-aviary1.1?
Summary: Ctrl+NumPad 0 does not restore Text Zoom to 100% → Ctrl+NumPad 0 does not restore Text Zoom to 100% if NumLock is off
*** Bug 313438 has been marked as a duplicate of this bug. ***
Attached patch WIP — — Splinter Review 
Would something like this be an acceptable solution?
(other platform/widget code need similar changes of course)
(In reply to comment #10)
>With NumLock off the number pad keys actually generate cursor keycodes so 0 is
>Insert and Ctrl+Num0 will paste (windows compatibility shortcut).
Apologies, Ctrl+Num0 on Windows is of course copy, not paste.
QA Contact: bugzilla → keyboard.navigation
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
Component: Keyboard: Navigation → User events and focus handling
Severity: minor → S4
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: