147927 - javascript focus() only moves the cursor not the focus

Status: RESOLVED FIXED

(Core :: DOM: Core & HTML, defect)

Description

[Allen Cook]

using the JavaScript .focus() property moves my cursor but not the keyboard focus.
After the call my cursor is in the desired text box; but the focus remains in a
select list; that would have been the next form element.  The cursor remains in
the text box assigned by the JavaScript .focus() call: unitl the actual keyboard
focus hits another text box.  This does not happen in IE5.5sp2 or NetScape 4.73

Comment 1

[Phil Schwartau]

Browser, not engine ---> DOM Level 0.

Allen, could you provide a reduced testcase or a URL to one?
We need to see exactly what's going wrong. Without that,
we'll have to close this bug. Also, please include the Mozilla
build ID in any bug report you file.

Note to attach a testcase, just go to the URL of this bug,
http://bugzilla.mozilla.org/show_bug.cgi?id=147927, and click 
on the "Create a New Attachment" link.


Compare:

bug 120995 
<input onblur="this.focus()"> doesn't work, the focus is not set

bug 109962 
Text input field doesn't get focus after HTMLInputElement.focus() 
(also on the onblur handler)

bug 53579  
calling this.blur()  in onfocus handler 
or      this.focus() in an onblur handler do not work 

Comment 2

[Allen Cook]

Attachment: test case, exhibits the described behavior

my current Mozilla build...
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.0rc3) Gecko/20020523
Mozilla 1.0 Release Candidate 3

Comment 3

[Allen Cook]

Attachment: better test form

includes one element that actually works in IE or Netscape this time.
and one that works in Netscape.
I still have not been able to get this to work in Mozilla.

Comment 4

[nick slussar]

Confirming bug, 2002061008/linux

Another testcase here: http://myxomop.com/bugzilla/focustest.html

Comment 5

[Boris Zbarsky [:bzbarsky]]

This worksforme on Linux... over to bryner, who may know what's up

Comment 6

[Brian Ryner (not reading)]

I suspect the checkin for bug 92525 may have fixed this as well.  Can someone
re-test?

Comment 7

[Allen Cook]

Bug is still present with Windows 2000 pro/ mozilla 1.1b 2002072104

However the bug does not exist with
Red Hat Linux 7.2 / mozilla 1.0 2002052918

Comment 8

[Brian Ryner (not reading)]

Actually, the wrong bug number was cited in the checkin comment.  Bug 138191 is
what may have actually fixed this.  This was checked in on 7/24; can you please
test a build from 7/25 or newer?

Comment 9

[Allen Cook]

It's still there used build 2002081218 in both Windows NT and Win 2000 Pro.
Both still have the bug.

Comment 10

[Kathleen :Brade]

*** Bug 135616 has been marked as a duplicate of this bug. ***

Comment 11

[Michael Lefevre]

reporter (Allen): can you reproduce this bug with a recent build of mozilla (for
example, 1.2)? if so, please comment again with details. if not, please resolve
this bug as WORKSFORME. thanks.

Comment 12

[Allen Cook]

build id: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2b) Gecko/20021016
OS Windows 2000 pro

Bug is still present. No change with the build listed above.

Comment 13

[Kai Lahmann (is there, where MNG is)]

Reporter: Can you reproduce this bug with a recent build of Mozilla (for
example, 1.4 RC1)? If so, then please comment again with details. If not, then
please resolve this bug as WORKSFORME. Thanks.

Comment 14

[Michael Lefevre]

using the second test with Mozilla trunk 2003072704 on win2k, this still happens.

confirming.

Comment 15

[Andrew Schultz]

*** Bug 217167 has been marked as a duplicate of this bug. ***

Comment 16

[Brian Ryner (not reading)]

Attachment: possible fix

I need to test this some more, I'm just putting the patch here so I don't lose
track of it.

Comment 17

[Brian Ryner (not reading)]

Comment on attachment 130613 [details] [diff] [review]
possible fix

This is a pretty simple change, which is along the same lines as my patch from
bug 53579.  That patch caused us to not focus what we thought was the new
focused content if blurring the old content changed the focus.	This is really
just a case that I missed there - if the blur handler focused some other
content, we don't want to clear that out by calling SetFocusedContent(nsnull). 
Note that this causes us t only null out the focused content in the case where
we _don't_ do an early return below.

Comment 18

[Johnny Stenback (:jst)]

Comment on attachment 130613 [details] [diff] [review]
possible fix

sr=jst

Comment 19

[Brian Ryner (not reading)]

Comment on attachment 130613 [details] [diff] [review]
possible fix

No response from John... blizzard, can you take a look?

Comment 20

[Brian Ryner (not reading)]

Comment on attachment 130613 [details] [diff] [review]
possible fix

Can I get this in for 1.6a?  I believe it's pretty safe; I've been running with
it in my tree for some time now.

Comment 21

[(not reading, please use [e-mail] instead)]

Comment on attachment 130613 [details] [diff] [review]
possible fix

a=sspitzer for 1.6a

Comment 22

[Brian Ryner (not reading)]

checked in.

Comment 23

[Mats Palmgren (inactive)]

In case this is considered for the 1.4 branch sometime in the future:
it could cause a regression (bug 232368), see also bug 118685.