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

NEW
Unassigned

Status

()

Core
Keyboard: Navigation
--
minor
15 years ago
9 years ago

People

(Reporter: Prognathous, Unassigned)

Tracking

({helpwanted})

Trunk
x86
All
helpwanted
Points:
---
Bug Flags:
blocking-aviary1.0PR -
blocking-aviary1.0 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment, 2 obsolete attachments)

(Reporter)

Description

15 years ago
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)

Updated

15 years ago
OS: Windows 2000 → All

Comment 1

15 years ago
Linux & OS/2 are not broken. all->not
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: All → Windows 2000
(Reporter)

Comment 2

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

Comment 3

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

Comment 4

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

Comment 5

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

Comment 6

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

Comment 7

15 years ago
Correction: you can't reset zoom using Ctrl+NumPad 0 if NumLock is off.

Comment 8

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

Comment 9

15 years ago
*** Bug 216710 has been marked as a duplicate of this bug. ***

Comment 10

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

Updated

14 years ago
Keywords: helpwanted

Comment 11

14 years ago
CC'ing Blake Ross and Gavin Sharp since they fixed bug 174854.

Updated

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

Comment 14

14 years ago
would take a patch for this but won't hold.  renominate if a patch appears
Flags: blocking-aviary1.0PR? → blocking-aviary1.0PR-

Comment 15

14 years ago
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. 
Created attachment 157196 [details] [diff] [review]
change default from ctrl++ to ctrl+= (aviary)

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)

Comment 17

14 years ago
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)
Created attachment 157206 [details] [diff] [review]
change default from ctrl++ to ctrl+= (moz1.7)

Same for 1.7 branch
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.
(Reporter)

Comment 21

14 years ago
(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.

Comment 22

14 years ago
(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.

Comment 24

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

Comment 25

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

Comment 26

14 years ago
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 27

14 years ago
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 28

14 years ago
Comment on attachment 157206 [details] [diff] [review]
change default from ctrl++ to ctrl+= (moz1.7)

Same here.
Attachment #157206 - Attachment is obsolete: true

Comment 29

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

Comment 31

14 years ago
*** Bug 262896 has been marked as a duplicate of this bug. ***
*** Bug 283905 has been marked as a duplicate of this bug. ***

Updated

13 years ago
Flags: blocking-aviary1.1?
(Reporter)

Comment 33

13 years ago
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. ***
Created attachment 200565 [details] [diff] [review]
WIP

Would something like this be an acceptable solution?
(other platform/widget code need similar changes of course)

Comment 36

12 years ago
(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.

Updated

9 years ago
QA Contact: bugzilla → keyboard.navigation
Mass un-assigning bugs assigned to Aaron.
Assignee: aaronleventhal → nobody
You need to log in before you can comment on or make changes to this bug.