507592 - Cannot change input field focus in Facebook login page

Status: VERIFIED FIXED

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

Description

[Tero Turtiainen]

User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090730 Minefield/3.6a1pre
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.9.2a1pre) Gecko/20090730 Minefield/3.6a1pre

Focus cannot be set to "First name" or any other input field on Facebook front page using the mouse, as the "Email" input field is focused when the page is loaded. To be able to focus to some other input field, one has to first click on the "Email" input field and then the input field you wanted to focus on.

Reproducible: Always

Steps to Reproduce:
1. Ensure you are not logged in to www.facebook.com
2. Browse to www.facebook.com
3. See that the "Email" input field is focused.
4. Click on "First name" input field.
Actual Results:  
"First name" input field does not get focus, "Email" input field still stays focused.

Expected Results:  
"First name" input field gets focus.

Works as expected in Minefield 2009-06-09-03 but is broken in 2009-06-11-03 and later. And between those versions was the great focus refactoring which propably breaks this functionality.

Comment 1

[Neil Deakin]

Attachment: reduced testcase

The page is doing:

<input onblur="this.select()">

which focuses and selects the contents. The same would happen if focus() was called instead of select().

This is correct behaviour, and I don't remember seeing it a few days ago while testing another bug.

Comment 2

[Neil Deakin]

> I don't remember seeing it a few days ago while
> testing another bug.

I mean I don't remember seeing this problem.

Comment 3

[Nochum Sossonko [:Natch]]

Can't block on an evangelism bug, but this is a pretty serious issue.

Comment 4

[Oleg Romashin (:romaxa)]

Attachment: This was not here before refactoring.

Before refactoring onSelect was just selecting content, but not grabbing focus.
And I did not found any comment about it...

I think it safe to remove it.

Comment 5

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 392104 [details] [diff] [review]
This was not here before refactoring.

Neil should review this (too).

Comment 6

[Olli Pettay [:smaug][[e-mail]]]

Comment on attachment 392104 [details] [diff] [review]
This was not here before refactoring.

textarea's select has similar code. It should be changed too, I think.
And this needs tests.

Comment 7

[Olli Pettay [:smaug][[e-mail]]]

Why is this evang bug? The behavior has changed, in fact regressed.

Comment 8

[Olli Pettay [:smaug][[e-mail]]]

Moving to another component so that we can track whether this is something to fix
for 1.9.2.

Comment 9

[Oleg Romashin (:romaxa)]

Attachment: TextArea included (need tests)

I think I don't have time to create tests and other things now.
Can someone else to do that?

Comment 10

[Neil Deakin]

I'm not understanding something here. The patches attached here don't fix this issue.

Comment 11

[Neil Deakin]

So it seems that the old code prevented refocusing the same element that was blurred during a blur event. For instance:

<input onblur="this.focus()">

Only this specific case is prevented. Focusing another element is still allowed, such as:

<input onblur="other.focus()">

This is the regression, although I suspect that preventing refocusing the element during a blur was not actually intentional behaviour. 

Implementing the old behaviour is a fairly simple change though.

Comment 12

[Johnny Stenback (:jst)]

I think we should fix this regression for 1.9.2. Neil, can you make sure this gets fixed?

Comment 13

[Neil Deakin]

I'm not convinced the current behaviour is an actual bug. Our current behavour of allowing refocus on blur matches IE, Safari and Chrome (although Safari has a caret drawing issue with it).

Comment 14

[Johnny Stenback (:jst)]

Neil, do the other browsers show this same bug then as well?

Comment 15

[Neil Deakin]

Attachment: the change is very easy though so I suppose there's no real disavantage to not doing so

Comment 16

[Neil Deakin]

http://hg.mozilla.org/mozilla-central/rev/97d2891732b4

Comment 17

[Daniel C]

What about comment 14? Should this behaviour be specced somewhere?

Comment 18

[Olli Pettay [:smaug][[e-mail]]]

(In reply to comment #17)
> Should this behaviour be specced somewhere?

It should, and some of it *may* be defined eventually in DOM 3 Events.

Comment 19

[Vane Lashua]

This sounds related, but may already be fixed in .19:

Cannot select Facebook "what's on your mind" input box, even after I have entered something else on the page. If I hit a key after having touched the box, "search in page" seems to be invoked ... first instance of the character is highlighted.
Vane Lashua

Comment 20

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed on trunk with Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.3a1pre) Gecko/20091009 Minefield/3.7a1pre ID:20091009030938

When can it be landed on 1.9.2?

Comment 21

[Neil Deakin]

http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fa1d53acc1bc

Comment 22

[Henrik Skupin [:whimboo][⌚️UTC+1]]

Verified fixed on 1.9.2 with builds on OS X and Windows

Mozilla/5.0 (Macintosh; U; Intel Mac OS X 10.5; en-US; rv:1.9.2b2pre) Gecko/20091028 Namoroka/3.6b2pre ID:20091028033705