Bug 8111 - REGRESSION (NativeTextField): first click in form field on weather.com leaves focus but no caret
Summary: REGRESSION (NativeTextField): first click in form field on weather.com leaves...
Status: RESOLVED FIXED
Alias: None
Product: WebKit
Classification: Unclassified
Component: Forms (show other bugs)
Version: 420+
Hardware: Macintosh OS X 10.4
: P1 Normal
Assignee: Darin Adler
URL: http://www.weather.com
Keywords: HasReduction, InRadar, Regression
Depends on:
Blocks:
 
Reported: 2006-03-31 15:50 PST by John Sullivan
Modified: 2006-04-05 22:53 PDT (History)
0 users

See Also:


Attachments
Picture of trouble-making form field  (32.88 KB, image/png)
2006-03-31 15:50 PST, John Sullivan
no flags Details
reduction (65 bytes, text/html)
2006-04-01 00:04 PST, Darin Adler
no flags Details
patch, including detailed change log and a layout test (32.75 KB, patch)
2006-04-05 09:15 PDT, Darin Adler
adele: review+
Details | Formatted Diff | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description John Sullivan 2006-03-31 15:50:05 PST
This bug is also in Radar as <rdar://4498729>

To reproduce:

1. visit http://www.weather.com
2. click in the field nearest the top of the page that contains the text "Enter city or US zip" (note that sometimes there's a 2nd field with this same text in it lower on the page in a Flash plug-in; I'm talking about the normal form field higher on the page -- see attached picture)

This click is supposed to erase the placeholder text, focus the field, and cause a caret to start blinking. The first two things happen, but there's no caret, and typing does not cause text to appear. A 2nd click in the field will set things right again.
Comment 1 John Sullivan 2006-03-31 15:50:56 PST
Created attachment 7425 [details]
Picture of trouble-making form field
Comment 2 Darin Adler 2006-04-01 00:04:59 PST
Created attachment 7434 [details]
reduction
Comment 3 Darin Adler 2006-04-01 00:07:27 PST
The cause of this is simple: The mouse event comes in and hit tests and gets an inner node, the text node inside the text field's div. Then, the script on the text field removes all the text, which makes that node get removed from the text field's div. Finally, we end up in Frame::handleMousePressEventSingleClick and we bail out because innerNode->renderer() is 0.

However, it's not clear to me what the right fix is. Maybe we need to do a new hit test after processing the focus change?
Comment 4 Darin Adler 2006-04-01 00:14:43 PST
I can think of two approaches to fix this:

    1) Change MouseEventWithHitTestResults to have an innerElement, and not an innerNode, so we'd never have a pointer to the text node in the first place. We'd probably want to change RenderObject::NodeInfo too if we did this.

    2) Change the FrameView::handleMousePressEvent function to fix up the MouseEventWithHitTestResults after calling dispatchMouseEvent.

I favor (1).
Comment 5 Chris Petersen 2006-04-01 18:48:19 PST
I'm seeing this issue at http://www.hotwire.com/index.jsp?lid=uhp.SMR06-01.jsp:topNav:loc:5:home

Clicking on either From or To fields displays a focus ring but doesn't display caret until a second click.
Comment 6 Maciej Stachowiak 2006-04-02 23:25:43 PDT
These are all text field regressions so they should all be P1.
Comment 7 Darin Adler 2006-04-05 09:15:22 PDT
Created attachment 7527 [details]
patch, including detailed change log and a layout test