Open Bug 641598 Opened 11 years ago Updated 6 years ago

Regression from Firefox 3.6: onblur event handler fires after calling focus()

Categories

(Core :: DOM: Events, defect)

x86_64
Linux
defect
Not set
normal

Tracking

()

People

(Reporter: imphil, Assigned: tnikkel)

References

(Blocks 2 open bugs)

Details

(Keywords: regression)

Attachments

(5 files)

Attached file testcase
I experienced this problem on http://www.farnell.de and reduced it to the attached testcase.

STR:
1. Load the testcase in Firefox 4 (I have here a nightly from 2011-03-14)
2. Move your mouse directly from the address bar to the input box and click in it

Expected behavior:
3a. The text inside the input should go away and the cursor blink inside the textbox.

Actual behavior:
3b. The gray text does not go away, the input field is not enabled. Entering text is not possible.


Now, to make this a bit more interesting, move your mouse around on the page, e.g. over the "button" for a couple seconds and then click in the input box again. Now the input receives focus and text input is possible.
Unfortunately, in this testcase I didn't find a 100% reproducible way to trigger to trigger the behavior that the input works again. 
On the original site however, it is more easily reproduced:

1. load http://farnell.de
2. from the address bar, go directly to the search input and click there: input does not become enabled.
3. mouseover the "Suchen" button
4. Now click into the search input: now it becomes active and it works as expected.


Firefox 3.6 shows the expected behavior, as does Konqueror 4.6.
Assignee: nobody → enndeakin
Keywords: regression
Perhaps from bug 591815?
(In reply to comment #3)
> Perhaps from bug 591815?

Yep, verified by undoing that patch.
Blocks: 591815
The NS_MOUSE_BUTTON_DOWN case of nsEventStateManager::PostHandleEvent doesn't seem to sanely handle the case where mCurrentTarget, aTargetFrame, and mCurrentTargetContent are all null.
Specifically the case where nsEventStatus_eConsumeNoDefault != *aStatus.
Bug 591815 was only about the prevent default case, so maybe for this case we should make the processing conditional on having a target frame like it was before bug 591815?
Attached patch diff -wSplinter Review
Should we just do this?
Attached patch patchSplinter Review
Attachment #520060 - Flags: review?(Olli.Pettay)
-w patch might make reviewing easier.
Oops, sorry, I somehow missed that comment.
Blocks: 642399
Comment on attachment 520060 [details] [diff] [review]
patch

We really need some tests here.

r=me if you add tests.
Attachment #520060 - Flags: review?(Olli.Pettay) → review+
Assignee: enndeakin → tnikkel
Blocks: 651297
Keywords: checkin-needed
Whiteboard: [needs landing][needs a tryserver check]
Timothy, have you posted this to the try server?
I have not.
Whiteboard: [needs landing][needs a tryserver check]
Thanks for sending that to try server.
Timothy, do you time to work on this?
Not at the moment, I was planning to come back to this, but if you want to pick it up feel free to do so.
Attached patch unbitrottedSplinter Review
Still fails
ERROR TEST-UNEXPECTED-FAIL | /tests/content/events/test/test_bug534833.html | Test timed out.
You need to log in before you can comment on or make changes to this bug.