Page font gets enlarged twice just by pressing Fn+/ (this simulates "+" from numeric keyboard) on an iBook

RESOLVED FIXED in Camino1.6

Status

Camino Graveyard
Accessibility
RESOLVED FIXED
13 years ago
11 years ago

People

(Reporter: Rimas Kudelis, Assigned: Stuart Morgan)

Tracking

({fixed1.8.1.12})

unspecified
Camino1.6
PowerPC
Mac OS X
fixed1.8.1.12

Details

Attachments

(1 attachment)

(Reporter)

Description

13 years ago
User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.8b4) Gecko/20050914 Camino/1.0a1

On iBooks, Fn+/ simulates a "+" from numeric keyboard. The problem is that, if I
press this key combination, while in Camino, it:
1) somehow forgets to check if I have Cmd key pressed, and enlarges all fonts;
2) does the above mentioned action twice.

Instead, it should think i've only pressed a "+" key, and react accordingly
(like, insert a "+" sign if i'm in a textfield atm).

Reproducible: Always

Steps to Reproduce:
1. get an iBook. I think, it will work with a powerbook, too;
2. open any page in Camino, preferably with an input field, and focus that field;
3. Press Fn and "/ ?" keys.

Actual Results:  
Text gets enlarged twice, and the text in the focused field doesn't change

Expected Results:  
Text should remain of the same size, and there should be an additional "+"
symbol in the textfield.

Comment 1

13 years ago
Confirming. I can reproduce this on a 15" AlBook running Tiger and a nightly.

Another problem with where key events are getting intercepted, maybe?

cl
Status: UNCONFIRMED → NEW
Ever confirmed: true

Comment 2

13 years ago
This doesn't require that a text field be focused, either. If FAYT is enabled,
it should start FAYT, but doesn't. The shift-= keystroke (a "normal" +) works as
expected.

cl
Oddly enough/thankfully, fn+; *doesn't* shrink the text back (you have to have
cmd pushed down, as one would expect, for that to work.)

As Chris noted, you don't have to have any page element focused, just the
content area in general (and in that case, the correct repsonse should be
nothing, just like a normal text-key keypress when the content area is focused).

Comment 4

13 years ago
Even weirder: if I num-lock the PowerBook's keyboard, the fn-keypad behaves
normally (identically to the numeric keypad on my Pro Keyboard).

cl
(Reporter)

Comment 5

13 years ago
(In reply to comment #4)
> Even weirder: if I num-lock the PowerBook's keyboard, the fn-keypad behaves
> normally (identically to the numeric keypad on my Pro Keyboard).

Yeah, and then if you use Fn and / (should still echo a plus) while numlock is
pressed, it enlarges font twice again. Meanwhile Fn+; (minus) again works as
expected...

Comment 6

13 years ago
(In reply to comment #5)
> (In reply to comment #4)
> > Even weirder: if I num-lock the PowerBook's keyboard, the fn-keypad behaves
> > normally (identically to the numeric keypad on my Pro Keyboard).
> 
> Yeah, and then if you use Fn and / (should still echo a plus) while numlock is
> pressed, it enlarges font twice again. Meanwhile Fn+; (minus) again works as
> expected...

OK, that part I can't reproduce. If the keyboard is num-locked, the fn key has
no effect on that portion of it. Fn-/ doesn't insert any characters, but it also
doesn't screw up the page.

cl

Comment 7

12 years ago
I add topic 339205 talking about this. Sorry.
This starts to happen in the lastest nightly built versions.

Laptop: FN + 7/8/9... opens all of my tabs... :)
Mass-reassign of bugs still assigned to pinkerton to nobody; filter on "NoMoPinkBugsInCamino".
Assignee: mikepinkerton → nobody
QA Contact: accessibility

Comment 9

11 years ago
Confirming. Reproduced on MacBook C2D both Tiger and Leopard. Also, it occurs only on Camino not on Firefox trunk.
(Assignee)

Comment 10

11 years ago
Created attachment 295331 [details] [diff] [review]
fix

I have no idea why pink didn't fix this when he fixed bug 339205...
Assignee: nobody → stuart.morgan
Status: NEW → ASSIGNED
Attachment #295331 - Flags: superreview?(mark)

Comment 11

11 years ago
Comment on attachment 295331 [details] [diff] [review]
fix

>+    if (([theEvent modifierFlags] & NSCommandKeyMask) != 0) {


Do we only want to check for the command key?  The next block down, for command-1 through command-9, checks that command is down and no other modifiers are down.  Guess it doesn't really matter.

>+      // If someone assigns this shortcuts to a menu, we want that to win.

Revise.
Attachment #295331 - Flags: superreview?(mark) → superreview+
(Assignee)

Comment 12

11 years ago
Landed on trunk and MOZILLA_1_8_BRANCH with the comment fixed. My understanding of the feature's intent is that we explicitly don't want to check for only the command key (e.g., shift-command-= should work for a US keyboard).
Status: ASSIGNED → RESOLVED
Last Resolved: 11 years ago
Keywords: fixed1.8.1.12
Resolution: --- → FIXED
Target Milestone: --- → Camino1.6
You need to log in before you can comment on or make changes to this bug.