Closed Bug 312756 Opened 19 years ago Closed 17 years ago

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

Categories

(Camino Graveyard :: Accessibility, defect)

PowerPC
macOS
defect
Not set
normal

Tracking

(Not tracked)

RESOLVED FIXED
Camino1.6

People

(Reporter: rimas, Assigned: stuart.morgan+bugzilla)

Details

(Keywords: fixed1.8.1.12)

Attachments

(1 file)

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.
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
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).
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
(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...
(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
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
Confirming. Reproduced on MacBook C2D both Tiger and Leopard. Also, it occurs only on Camino not on Firefox trunk.
Attached patch fixSplinter Review
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 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+
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
Closed: 17 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.

Attachment

General

Creator:
Created:
Updated:
Size: