Closed Bug 507592 Opened 13 years ago Closed 13 years ago

Cannot change input field focus in Facebook login page

Categories

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

defect

Tracking

()

VERIFIED FIXED
mozilla1.9.3a1
Tracking Status
status1.9.2 --- beta1-fixed

People

(Reporter: moz_poro, Assigned: enndeakin)

References

()

Details

(Keywords: regression, top100, verified1.9.2)

Attachments

(2 files, 2 obsolete files)

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.
Blocks: 178324
Attached file 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.
> I don't remember seeing it a few days ago while
> testing another bug.

I mean I don't remember seeing this problem.
Assignee: nobody → english-us
Status: UNCONFIRMED → NEW
Component: XUL → English US
Ever confirmed: true
Product: Core → Tech Evangelism
QA Contact: xptoolkit.widgets → english-us
Can't block on an evangelism bug, but this is a pretty serious issue.
Severity: normal → major
Keywords: top100
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.
Attachment #392104 - Flags: review?(Olli.Pettay)
Attachment #392104 - Flags: review?(enndeakin)
Comment on attachment 392104 [details] [diff] [review]
This was not here before refactoring.

Neil should review this (too).
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.
Attachment #392104 - Flags: review?(enndeakin)
Attachment #392104 - Flags: review?(Olli.Pettay)
Attachment #392104 - Flags: review-
Why is this evang bug? The behavior has changed, in fact regressed.
Assignee: english-us → nobody
Component: English US → DOM
Product: Tech Evangelism → Core
QA Contact: english-us → general
Moving to another component so that we can track whether this is something to fix
for 1.9.2.
Flags: blocking1.9.2?
Attached patch TextArea included (need tests) (obsolete) — Splinter Review
I think I don't have time to create tests and other things now.
Can someone else to do that?
Attachment #392104 - Attachment is obsolete: true
I'm not understanding something here. The patches attached here don't fix this issue.
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.
I think we should fix this regression for 1.9.2. Neil, can you make sure this gets fixed?
Assignee: nobody → enndeakin
Flags: blocking1.9.2? → blocking1.9.2+
Keywords: regression
Priority: -- → P2
Target Milestone: --- → mozilla1.9.2
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).
Neil, do the other browsers show this same bug then as well?
Attachment #402369 - Flags: review?(Olli.Pettay) → review+
http://hg.mozilla.org/mozilla-central/rev/97d2891732b4
Status: NEW → RESOLVED
Closed: 13 years ago
Flags: in-testsuite+
Resolution: --- → FIXED
What about comment 14? Should this behaviour be specced somewhere?
(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.
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
Target Milestone: mozilla1.9.2 → mozilla1.9.3a1
Attachment #392109 - Attachment is obsolete: true
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?
Status: RESOLVED → VERIFIED
OS: Linux → All
Hardware: x86 → All
Version: unspecified → Trunk
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
Keywords: verified1.9.2
Component: DOM → DOM: Core & HTML
You need to log in before you can comment on or make changes to this bug.