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)
Tracking
(Not tracked)
RESOLVED
FIXED
Camino1.6
People
(Reporter: rimas, Assigned: stuart.morgan+bugzilla)
Details
(Keywords: fixed1.8.1.12)
Attachments
(1 file)
1.85 KB,
patch
|
mark
:
superreview+
|
Details | Diff | Splinter Review |
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•19 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•19 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•19 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•19 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•19 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•18 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•17 years ago
|
||
Confirming. Reproduced on MacBook C2D both Tiger and Leopard. Also, it occurs only on Camino not on Firefox trunk.
Assignee | ||
Comment 10•17 years ago
|
||
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•17 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•17 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
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.
Description
•