Bug 8741 – Keyfocus regression at http://www.mochikit.com/examples/interpreter/index.html

• Status: RESOLVED
• Resolution: FIXED
• Component: Forms

[Eric Seidel (no email)]

Go to http://www.mochikit.com/examples/interpreter/index.html

type "1" <enter> in the console.
Now the text field looks like it has focus, but it doesn't.  (delete goes back, space scrolls, etc.)

Created attachment 8357 [details]
Potential Test Case Reduction

I've been having problems with form fields losing focus during JavaScript execution as well, even though the blue border indicating focus remains around the field. It looks like the bug I've found is related to this one.

I've attached a test case reduction for the problem I've been experiencing with a website's login form. Type into the userid field, wait 1/4 second, and then attempt to type another letter.

In Safari 417.9.3 (as well as Firefox) this form works as expected, but in 420+ you can no longer interact with the text box without clicking on it between each key press.

(In reply to comment #1)

Sorry for the second message, but to clarify the test case: In order for the bug to exhibit you have to type a lower-case letter into the text field. If you type an upper-case letter, a number, or a symbol that the call to value.toUpperCase() does not modify then focus will remain in the text field.

[Darin Adler]

This looks like the same problem as bug 8660.

[Alice Liu]

<rdar://problem/4578090>

[Alain O'Dea]

I have a similar problem with focus in Gmail on my PowerBook. Using a nightly WebKit reporting Version 2.0.3 (417.9.3) paste does not work from the keyboard in Gmail. If I try to paste the input field or text area loses focus and I get a system beep. The field or area also loses focus when hitting any of the arrow keys. It seems like losing focus happens with anything other than clicks, textual keystrokes, or backspace. Using Fn-Delete to forward delete also causes focus to be lost as do any other attempts to use Fn-key combinations for things like the numeric keypad or page up/page dn/home/end.

[Alain O'Dea]

Gmail focus problem disappeared when I switched to the 23 June 2006 nightly build. Arrow keys and Fn-key combos like forward delete and number pad edit the content of the field normally and don't cause loss of focus as they did in the previous build I was using. Home/End/Page Up/Page Down still don't move the caret within the field as I would like, but I suspect this is by design since it is consistent with the last Safari release.

Side note: the About Safari item in the Safari menu in WebKit should list the nightly build identifier to make it easier to track user-filed regressions and improvements like this one.

[David Kilzer (:ddkilzer)]

(In reply to comment #6)
> Side note: the About Safari item in the Safari menu in WebKit should list the
> nightly build identifier to make it easier to track user-filed regressions and
> improvements like this one.

You need to report the name of the nightly build (preferably the SVN revisions number, rNNNNN) when filing bugs or commenting on bugs.  The About box for Safari is Safari's version and build number, not WebKit's.  See this web page:

http://developer.apple.com/internet/safari/uamatrix.html

I agree that it would be nice if Safari could dynamically query WebKit for its version number, though.

[David Kilzer (:ddkilzer)]

(In reply to comment #7)
> I agree that it would be nice if Safari could dynamically query WebKit for its
> version number, though.

Filed <rdar://problem/4601196> to ask Safari to report its WebKit build number through its About box.

[Alice Liu]

Is this still happening for anyone else?  With the latest nightly, the focus seems fixed.  Delete and space function as you'd expect with the text field focused.  

[Mark Rowe (bdash)]

The focus problems are not present for me in r15138.  The last nightly build to exhibit this issue was r14926.  It seems that r14932 is the likely candidate for having fixed this.

[Mark Rowe (bdash)]

Err, that should have been r14931 that was the likely fix.