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

Status: RESOLVED DUPLICATE of bug 807685

(Core :: Widget: Cocoa, defect)

Description

[Dirkjan Ochtman (:djc)]

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).

Comment 1

[Dirkjan Ochtman (:djc)]

Still seeing this with latest Aurora, even with a fresh profile. Can someone please take a look?

Comment 2

[Dirkjan Ochtman (:djc)]

This works on Windows 7, so it's probably OS X-specific. Might be Lion-specific?

Comment 3

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 4

[juan becerra [:juanb]]

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.

Comment 5

[Nick Lowe]

Isn't this controlled by ApplePressAndHoldEnabled?

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

I don't think this is a bug...

Comment 6

[Chris Lawson (gone)]

(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.

Comment 7

[Nick Lowe]

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.

Comment 8

[Chris Lawson (gone)]

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).

Comment 9

[Dirkjan Ochtman (:djc)]

Could this get some attention, please? It seems like a pretty annoying regression (though obviously not a show stopper).

Comment 10

[Kevin Brice]

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.

Comment 11

[Dirkjan Ochtman (:djc)]

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?

Comment 12

[Josh Aas]

Steven - can you look into this?

Comment 13

[Dirkjan Ochtman (:djc)]

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.

Comment 14

[Steven Michaud [:smichaud] (Retired)]

> 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.

Comment 15

[Seth Fowler [:seth] [:s2h]]

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.

Comment 16

[Florian Bender]

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?).

Comment 17

[Steven Michaud [:smichaud] (Retired)]

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.

Comment 18

[Florian Bender]

Feel free to do so, I don't have editbugs privileges :)