Cannot change input field focus in Facebook login page

VERIFIED FIXED in mozilla1.9.3a1

Status

()

Core
DOM
P2
major
VERIFIED FIXED
8 years ago
8 years ago

People

(Reporter: Tero Turtiainen, Assigned: Neil Deakin)

Tracking

({regression, top100, verified1.9.2})

Trunk
mozilla1.9.3a1
regression, top100, verified1.9.2
Points:
---
Bug Flags:
blocking1.9.2 +
in-testsuite +

Firefox Tracking Flags

(status1.9.2 beta1-fixed)

Details

(URL)

Attachments

(2 attachments, 2 obsolete attachments)

(Reporter)

Description

8 years ago
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.
(Reporter)

Updated

8 years ago
Blocks: 178324
(Assignee)

Comment 1

8 years ago
Created attachment 391899 [details]
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.
(Assignee)

Comment 2

8 years ago
> 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
Created attachment 392104 [details] [diff] [review]
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.
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?
Created attachment 392109 [details] [diff] [review]
TextArea included (need tests)

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
(Assignee)

Comment 10

8 years ago
I'm not understanding something here. The patches attached here don't fix this issue.
(Assignee)

Comment 11

8 years ago
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
(Assignee)

Comment 13

8 years ago
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?
(Assignee)

Comment 15

8 years ago
Created attachment 402369 [details] [diff] [review]
the change is very easy though so I suppose there's no real disavantage to not doing so
Attachment #402369 - Flags: review?(Olli.Pettay)
Attachment #402369 - Flags: review?(Olli.Pettay) → review+
(Assignee)

Comment 16

8 years ago
http://hg.mozilla.org/mozilla-central/rev/97d2891732b4
Status: NEW → RESOLVED
Last Resolved: 8 years ago
Flags: in-testsuite+
Resolution: --- → FIXED

Comment 17

8 years ago
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.

Comment 19

8 years ago
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
(Assignee)

Comment 21

8 years ago
http://hg.mozilla.org/releases/mozilla-1.9.2/rev/fa1d53acc1bc
status1.9.2: --- → beta1-fixed
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
You need to log in before you can comment on or make changes to this bug.