Closed Bug 686113 Opened 13 years ago Closed 11 years ago

[10.7] Character repeat on long button presses doesn't work


(Core :: Widget: Cocoa, defect)

Not set





(Reporter: djc, Assigned: smichaud)


(Blocks 1 open bug)


(Whiteboard: [10.7][qa+])

I first noticed this yesterday, on OS X (Lion 10.7.1) Aurora (latest 8.0a2). When typing in textarea or input[type="text"], either in chrome (location bar) or in content, pressing a letter key for a long time does no longer generate lots of characters, but just stays at the first letter. It still works in other apps, so it doesn't seem to be a problem with my OS settings. It also persisted throughout a reboot of my laptop (2009-era MBP).
Still seeing this with latest Aurora, even with a fresh profile. Can someone please take a look?
This works on Windows 7, so it's probably OS X-specific. Might be Lion-specific?
Component: Shell Integration → Widget: Cocoa
Product: Firefox → Core
QA Contact: shell.integration → cocoa
I can reproduce this in FF 6.0.2 on Lion (10.7.1), but not on OS X 10.5.8 (for the moment I'm not able to test on OS X 10.6.8).

Yes, this is probably another Lion bug.  But I'll wait to mark it as such until I've had a chance to test on 10.6.8.
On 10.7 neither the nightly nor Chrome work as expected. On 10.6.8 both work as expected.

This seems like a Lion issue.
Whiteboard: [10.7][qa+]
Summary: Character repeat on long button presses doesn't work → [10.7] Character repeat on long button presses doesn't work
Hardware: x86_64 → All
Version: 8 Branch → Trunk
Isn't this controlled by ApplePressAndHoldEnabled?

"defaults write -g ApplePressAndHoldEnabled -bool false" should allow character repeat.

I don't think this is a bug...
(In reply to Nick Lowe from comment #5)
> Isn't this controlled by ApplePressAndHoldEnabled?

From comment 0:

> It still works in other apps, so it doesn't seem to be a problem with my OS settings.
Can you try opening Terminal then, putting...

defaults write -g ApplePressAndHoldEnabled -bool false

... in and then pressing enter.

Log off and log on again, and try to reproduce.
Nick, I'm pretty sure Steven and Juan know what they're doing, even if the reporter doesn't (and he seems like he does, too).
Could this get some attention, please? It seems like a pretty annoying regression (though obviously not a show stopper).
It appears Firefox is following the new behavior in Lion, but only for keys that don't show the new accent selection menu on hold. By default, holding keys such as "k" and "f" works exactly the same as in Safari and TextEdit - one letter is entered and holding the key doesn't cause any repeating characters to appear. However, keys such as "e" and "c", which in Safari and TextEdit display a menu offering accent choices, *do* repeat in Firefox. The behavior is inconsistent and would be highly confusing for an end-user. Firefox should either universally ignore the setting in Lion or, ideally, display the Lion accent selection menu instead of simply repeating characters only for those select letters.
I, like Kevin, noticed that it's only a problem with some keys. It's still quite confusing, and I'm surprised noone has investigated this further. Is there anything I could do to help out?
Steven - can you look into this?
Assignee: nobody → smichaud
Okay, so, in the end defaults write -g ApplePressAndHoldEnabled -bool false, then logging out and back in did work for me. I thought I tried it and it didn't work. So I guess this bug should be closed in favor of something to make the new character picker work.
> Steven - can you look into this?

I've been meaning to get to this for a while.  But I'm afraid it'll still be a while longer.
Registering my interest in fixing this bug. The right fix is _definitely_ to display the accent selection menu. It's a pain to enter text in languages that use accents in Firefox right now.
See Also: → 807685
Bug 752452 is probably a duplicate of this bug. Can somebody please mark it as such? 

Also, Bug 807685 Comment 4 and following have an update on this issue (shouldn't bug 807685 be marked as a duplicate of this bug, anyway?).
I'd say both this bug and bug 752452 should probably be marked as duplicates of bug 807685.  Bug 807685 seems to have the best information of all.

And no, I still don't know when I'll have time to work on these bugs.
Feel free to do so, I don't have editbugs privileges :)
Closed: 11 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.