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.
Created attachment 7425 [details] Picture of trouble-making form field
Created attachment 7434 [details] reduction
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?
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).
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.
These are all text field regressions so they should all be P1.
Created attachment 7527 [details] patch, including detailed change log and a layout test