1. Go to http://www.google.com/advanced_search. 2. Press a letter key. Notice that the first textbox on the page has focus, but the insertion point isn't visible. In IE and Nav4, the textbox has focus and you can see the insertion point.

Hmm, ie doesn't give focus at all for that testcase. (ns4 does, though.)

reassigning

handing over to jfrancis

simon, sounds like event woes...

Over to anthonyd.

hmmm, this one is wierd. Focus is definitely in the field, but why isn't the caret being drawn? I will investigate this further, and will once again, cc Saari on this one. anthonyd

QA Contact Update

moving to mozilla 0.9.1

move to mozilla0.9.2

this is still an issue using the build from 2001052020, the only way I can get the caret to render in the 1st textbox is to go to the next textbox and shift+tab back to it, clicking in the textbox doesn't do it, moving to 1.0

For me the carret is invisible only the first time you click into the field. After you click on another field and click back I can see it. This is on build 2001-05-22-06-trunk. Also in the testcase the table, which at first has some space under the text field shrinks once you start typing in the field.

> For me the carret is invisible only the first time you click into the field. Since a script on the page does a textbox.focus(), you don't have to click in the field to reproduce this bug. The insertion point is already in the field, and characters typed do go into the field. (Note that the script that focuses the textbox is inline rather than onload.)

*** Bug 89378 has been marked as a duplicate of this bug. ***

this is still occuring on window2000 build - 20010719

in the attached testcase, if you move </td></tr></table> back inside of the <form></form> in a more proper nested fashion, it works. Neat.

--> kin

--> mjudge (caret/selection)

Is this bug representative of a large class of sites that are broken? If the only place we see this is on that one page, then I question the EDITORBASE nomination. Perhaps a very small evangelism effort would fix the specific problem on that page given what saari discovered.

I'd think that only sites with improper tag nesting would be broken since the syntactically correct html works fine.

looks to me like it occurs on sites which use the javascript focus() method.

no, there are many sites that use js focus just fine. It is something more specific than that. As I noted, this case can be fixed by proper tag nesting.

Problem occurs on Mac OS 8.6, 9.0.4, 9.1, and X. Using build id 2001112608.

marking this future. this is a table embedding wierd tag case. If this must be requalified give it to someone in tables.

Changing platform and OS to all / all per comment 23.

*** Bug 120852 has been marked as a duplicate of this bug. ***

*** Bug 130707 has been marked as a duplicate of this bug. ***

*** Bug 151524 has been marked as a duplicate of this bug. ***

According to bug 51897 comment 14, this was fixed in bug 90756. *** This bug has been marked as a duplicate of 90756 ***

verifying, it is fixed on 2002-07-01-08-trunk

Acting on Duplicate resolution from bug 64450 comment 29: *Moving 'Blocks: bug 64451' from bug 64450 to bug 90756. (Take further action as needed.)