Last Comment Bug 167801 - Cursor (caret) sometimes fails to appear in input text fields (shown/painted in wrong widget)
: Cursor (caret) sometimes fails to appear in input text fields (shown/painted ...
Status: RESOLVED FIXED
: testcase
Product: Core
Classification: Components
Component: Selection (show other bugs)
: Trunk
: All All
: -- normal with 26 votes (vote)
: ---
Assigned To: Blake Kaplan (:mrbkap) (PTO until Jan. 2, 2017)
:
: Jet Villegas (:jet)
Mentors:
: 210535 212732 216353 223239 237298 256020 258345 272577 279198 283044 298454 298615 308151 310490 319394 322130 329997 349237 349238 358322 359439 360253 362883 364480 364669 381928 387449 437595 (view as bug list)
Depends on: 287813
Blocks: 58359 188517 226933 230701 257443
  Show dependency treegraph
 
Reported: 2002-09-10 13:56 PDT by Bill Walsh
Modified: 2010-07-30 19:37 PDT (History)
80 users (show)
darin.moz: blocking1.8.1-
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---


Attachments
This sample illustrates the behavior where the cursor sometimes fails to appear in input text fields. (6.40 KB, text/html)
2002-09-10 13:58 PDT, Bill Walsh
no flags Details
simpler testcase (256 bytes, text/html)
2002-09-12 22:03 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
workaround (285 bytes, text/html)
2003-06-05 10:41 PDT, Robert O'Callahan (:roc) (email my personal email if necessary)
no flags Details
Another simple testcase (caret partialy showed) (1.25 KB, text/html)
2005-06-22 23:21 PDT, Rastislav Graus
no flags Details
Another Simple Workaround (258 bytes, text/html)
2005-07-29 12:00 PDT, anonymous
no flags Details
Simple Tabbed View showing bug (2.29 KB, text/html)
2005-11-17 10:40 PST, Paul Raines
no flags Details
Simple Tabbed View showing workaround (2.24 KB, text/html)
2005-11-17 10:42 PST, Paul Raines
no flags Details
Cursor is not shown even when the DIV is hidden (162 bytes, text/html)
2005-12-06 05:15 PST, Alexander Netkachev
no flags Details
z-Index testcase (1.47 KB, text/html)
2006-11-16 11:14 PST, Edemilson Lima
no flags Details
the cursor in the text-box disappears over an iframe. (365 bytes, text/html)
2006-12-05 01:31 PST, tobias
no flags Details
the cursor in the text-box disappears over an iframe.(fixed) (683 bytes, text/html)
2007-12-19 23:05 PST, rajeswaran
no flags Details

Description Bill Walsh 2002-09-10 13:56:29 PDT
User-Agent:       Mozilla/4.0 (compatible; MSIE 5.5; Windows NT 5.0)
Build Identifier: Mozilla 1.1 [User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1) Gecko/20020826]

Cursor sometimes fails to appear in input text fields. Tested with Mozilla 1.1 
[User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.1)
Gecko/20020826]. Also occurs with earlier versions of Mozilla. This behavior 
only occurs when a div1 has scrollbars and the input text field in another div 
(div2) overlaps div1.

An example HTML testcase is provided to illustrate this behavior.


Reproducible: Always

Steps to Reproduce:
1.
2.
3.
Comment 1 Bill Walsh 2002-09-10 13:58:31 PDT
Created attachment 98624 [details]
This sample illustrates the behavior where the cursor sometimes fails to appear in input text fields.
Comment 2 Bill Walsh 2002-09-10 14:00:47 PDT
This bug seems to be similar to the behavior described in bugs #143777 and 
#144419.
Comment 3 John Keiser (jkeiser) 2002-09-12 21:43:26 PDT
Excellent testcase.  -> selection, I suspect, though Roc may have some theories
here.
Comment 4 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-09-12 22:03:42 PDT
Created attachment 99019 [details]
simpler testcase
Comment 5 Robert O'Callahan (:roc) (email my personal email if necessary) 2002-09-12 22:12:46 PDT
What's happening here is that the code to paint the caret is just trying to draw
the caret in the widget which contains the frame the caret's in. But that
doesn't work because that widget is covered by the widget for the DIV. The view
manager paints everything correctly (i.e., the text that gets entered) because
it coordinates painting across widgets and knows to draw the input text box
frame inside the DIV's widget.

Fixing this could be tough. Only the view manager knows how z-order and clipping
work. To fix this we should probably move caret painting into the view manager.
Or maybe we can paint the caret using the normal paint path?
Comment 6 Robert O'Callahan (:roc) (email my personal email if necessary) 2003-06-05 10:41:20 PDT
Created attachment 125003 [details]
workaround

Here's a version of attachment 99019 [details] that works around this problem.

There are two important changes:
-- The textbox is wrapped in a positioned DIV that is marked 'overflow:auto'.
'overflow:auto' ensures that the textbox DIV has a native widget associated
with it.
-- The textbox DIV appears in the DOM after the red DIV. This ensures that the
native widget for the textbox is ordered after the native widget for the red
DIV.
Comment 7 Roman J. Mashirov 2003-11-13 04:51:41 PST
Seems bug 216353 is the same thing.

Given workaround does not works for me in Mozilla/5.0 (X11; U; Linux i686;
ru-RU; rv:1.4) Gecko/20030701
Comment 8 José Jeria 2004-02-17 15:44:37 PST
*** Bug 216353 has been marked as a duplicate of this bug. ***
Comment 9 Boris Zbarsky [:bz] (still a bit busy) 2004-05-02 12:04:38 PDT
*** Bug 237298 has been marked as a duplicate of this bug. ***
Comment 10 Boris Zbarsky [:bz] (still a bit busy) 2004-05-02 12:04:51 PDT
*** Bug 212732 has been marked as a duplicate of this bug. ***
Comment 11 Boris Zbarsky [:bz] (still a bit busy) 2004-05-02 12:06:19 PDT
*** Bug 210535 has been marked as a duplicate of this bug. ***
Comment 12 Mats Palmgren (:mats) 2004-09-10 16:46:12 PDT
*** Bug 256020 has been marked as a duplicate of this bug. ***
Comment 13 Jason Barnabe (np) 2004-12-04 12:13:11 PST
*** Bug 272577 has been marked as a duplicate of this bug. ***
Comment 14 Chris Thomas (CTho) [formerly cst@andrew.cmu.edu cst@yecc.com] 2005-01-20 19:20:44 PST
*** Bug 279198 has been marked as a duplicate of this bug. ***
Comment 15 Mats Palmgren (:mats) 2005-02-21 14:56:36 PST
*** Bug 283044 has been marked as a duplicate of this bug. ***
Comment 16 Paul Raines 2005-02-21 15:14:14 PST
Should I assume this bug is not considered serious since has been over two years?
It makes it a pain to use Firefox on those sites using CSS to emulate tabbed
forms.
Comment 17 Ricardo Lopez 2005-04-27 08:33:29 PDT
Is this bug in the realm of being considered?
Comment 18 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-04-27 13:04:41 PDT
mrbkap is working on a fix but it won't make 1.8/FF 1.1.
Comment 19 José Jeria 2005-06-22 11:05:46 PDT
*** Bug 223239 has been marked as a duplicate of this bug. ***
Comment 20 Rastislav Graus 2005-06-22 23:21:16 PDT
Created attachment 187105 [details]
Another simple testcase (caret partialy showed)
Comment 21 José Jeria 2005-06-24 04:47:03 PDT
*** Bug 298615 has been marked as a duplicate of this bug. ***
Comment 22 anonymous 2005-07-29 12:00:37 PDT
Created attachment 190975 [details]
Another Simple Workaround

I'm not sure whether this is relevant, but changing the input's position from
"absolute" to "fixed" causes the caret to appear.
Comment 23 José Jeria 2005-08-10 10:42:40 PDT
*** Bug 298454 has been marked as a duplicate of this bug. ***
Comment 24 Uri Bernstein (Google) 2005-08-18 10:38:43 PDT
*** Bug 258345 has been marked as a duplicate of this bug. ***
Comment 25 C Qualset 2005-08-22 11:43:34 PDT
(In reply to comment #22)
> Created an attachment (id=190975) [edit]
> Another Simple Workaround
> 
> I'm not sure whether this is relevant, but changing the input's position from
> "absolute" to "fixed" causes the caret to appear.

I tried this and it works for FireFox, but the IE results are not the same.

Comment 26 José Jeria 2005-09-12 11:35:28 PDT
*** Bug 308151 has been marked as a duplicate of this bug. ***
Comment 27 Adam Guthrie 2005-09-29 12:34:24 PDT
*** Bug 310490 has been marked as a duplicate of this bug. ***
Comment 28 Masayuki Nakano [:masayuki] (Mozilla Japan) 2005-11-01 06:30:31 PST
We can reproduce this bug on Win/Linux/Mac(except Camino).

-> All/All
Comment 29 Dietrich Streifert 2005-11-05 03:15:47 PST
We can reproduce this on

Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.7.12) Gecko/20050919 Firefox/1.0.7

and

Mozilla/5.0 (Windows; U; Windows NT 5.0; de; rv:1.8) Gecko/20051025 Firefox/1.5

and run into serious problems with implementing our web application.

Please fix this bug!
Comment 30 Ross Dargahi (Zimbra) 2005-11-07 01:55:41 PST
We can also reproduce this bug on both 1.0.7 and 1.5 (CR1) on windows:

This is an incredibly painful bug and not only makes applications look bad, but also makes FireFox look bad. It will become more and more visible as AJAX applications start proliferating. Please please please fix this bug
Comment 31 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-11-07 14:56:26 PST
The fix is almost done and will land in 1.9 but not in Firefox 1.5. The workarounds mentioned in this bug are the best we can offer for FF1.5.
Comment 32 jirizarry 2005-11-14 11:45:40 PST
(In reply to comment #31)
> The fix is almost done and will land in 1.9 but not in Firefox 1.5. The
> workarounds mentioned in this bug are the best we can offer for FF1.5.
> 

Is there any proposed scheduled release date for version 1.9? 
We are currently implementing a grid control that requires the appearance of the cursor for editing text within textarea fields embedded in the grid. The cursor only appears for Internet Explorer users. I am trying to avoid making I.E. a requirement for this new control. Please advise.
Comment 33 Robert O'Callahan (:roc) (email my personal email if necessary) 2005-11-14 12:35:59 PST
(In reply to comment #32)
> Is there any proposed scheduled release date for version 1.9? 

A year from now, more or less.

> We are currently implementing a grid control that requires the appearance of
> the cursor for editing text within textarea fields embedded in the grid. The
> cursor only appears for Internet Explorer users. I am trying to avoid making
> I.E. a requirement for this new control. Please advise.

Try one of these workarounds.
Comment 34 Paul Raines 2005-11-17 10:40:02 PST
Created attachment 203423 [details]
Simple Tabbed View showing bug

This is a simple Tabbed View interface showing the caret bug where the caret is invisible in the text fields of the first tab.
Comment 35 Paul Raines 2005-11-17 10:42:41 PST
Created attachment 203425 [details]
Simple Tabbed View showing workaround

Same Tabbed View as above, but showing workaround where DIV's are replaced with TABLES
Comment 36 Alexander Netkachev 2005-12-06 05:15:00 PST
Created attachment 205135 [details]
Cursor is not shown even when the DIV is hidden
Comment 37 Adam Guthrie 2006-01-02 20:08:14 PST
*** Bug 322130 has been marked as a duplicate of this bug. ***
Comment 38 Garret Wilson 2006-01-26 15:31:32 PST
(In reply to comment #33)
> (In reply to comment #32)
> > Is there any proposed scheduled release date for version 1.9? 
> 
> A year from now, more or less.

That's more than a disappointment---it's inappropriate. After years of complaining about IE's weird requirement of giving controls "layout" to make them position correctly (see http://www.satzansatz.de/cssd/onhavinglayout.html ), we find that we have to do something similar (with a similar cause) in Firefox just to get a cursor. With AJAX becoming more popular, this is a problem that will be showing up again and again---every AJAX application will want to put up a DIV-based popup containing a text INPUT.

> Try one of these workarounds.

All of these "workarounds" only "work" for test pages for which you know in advance the exact pixel layout and for which you don't care if it works on IE. None of the "workarounds" deal with the more common real-life scenario of having a popup containing flowed content such as an AJAX framework might generate:

<div class="popupFrame">
  <input/>
</div>

We just started testing a large application for a vertical market that uses AJAX, only to find that all of the popups lose the cursor on Firefox. We can't wait a year to get it fixed, and we need a workaround now for Firefox 1.0x and 1.5. Can anyone give a suggestion---please?
Comment 39 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-01-26 15:53:47 PST
(In reply to comment #38)
> <div class="popupFrame">
>   <input/>
> </div>

If you make that div 'overflow:auto', you should get the caret. If you don't, can you submit a testcase?
Comment 40 Garret Wilson 2006-01-26 17:32:17 PST
(In reply to comment #39)
> (In reply to comment #38)
> > <div class="popupFrame">
> >   <input/>
> > </div>
> 
> If you make that div 'overflow:auto', you should get the caret.

Well, yes and no---and I've found the problem.

Behind our floating DIV we were putting a separate blanket DIV to keep user input from the main page, effectively creating a modal popup. That in itself is not a problem, except that IE uses native window components for SELECT elements, which would shine through the blanket DIV (a situation caused by issues not unrelated to this Mozilla bug). One of the only solutions is to slide in an IFrame to cover up native SELECT components on IE. You guessed it---the IFrame on Mozilla will take away the text INPUT cursor, even with "overflow: auto". Voila: a related issue on two platforms that calls for mutually exclusive workarounds.

We now (horrors!) do browser detection, and use IFrames for IE only, which allows our separate workarounds to work on both IE and Mozilla.

Thanks for your feedback.
Comment 41 Brian Rakowski 2006-02-07 09:16:21 PST
Is this related to https://bugzilla.mozilla.org/show_bug.cgi?id=226933
Comment 42 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-02-09 00:32:45 PST
We can fix this on the trunk soon, as soon as mrbkap has some time, or else I'll just do it myself.

On the 1.8.1 branch, we can probably adapt the trunk strategy to work through the view manager, if it's really worth doing. I'm not sure if it is. Of course if say Brian wants to fix it then no problem :-)
Comment 43 fkhoz 2006-02-22 14:34:24 PST
Not sure if this is a related bug, but the cursor does not seem to show anytime there is a textarea over an iframe in Firefox.  Try the following.

<iframe src="http://www.yahoo.com" scrolling="no" style="position:absolute; width:200px; height:200px; left:0px; top:0px"></iframe>
<textarea style="position:absolute;  width:100px; height:50px; left:0px; top:0px">cursor does NOT show</textarea>
<textarea style="position:absolute;  width:100px; height:50px; left:0px; top:100px">cursor does NOT show</textarea>
<textarea style="position:absolute;  width:100px; height:50px; left:0px; top:200px">cursor does shows</textarea>
Comment 44 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-03-10 02:54:18 PST
*** Bug 329997 has been marked as a duplicate of this bug. ***
Comment 45 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-03-10 02:55:16 PST
*** Bug 319394 has been marked as a duplicate of this bug. ***
Comment 46 Mike Shaver (:shaver -- probably not reading bugmail closely) 2006-04-18 10:51:34 PDT
Optimistic blocker+, want to hear more about the branch approach ASAP though.
Comment 47 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-04-18 13:09:32 PDT
On branch, we'd have to hack the view manager's display list to ensure that CreateDisplayList always descends to the view containing the caret. I'd have a new display flag PAINT_CARET for view display items. When we see this flag we would paint the caret from the view manager just after we call PresShell::Paint. The invalidation and nsCaret changes from the trunk patch could probably be ported over with few changes.

shaver, let me know who you imagine doing this, and why.
Comment 48 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-04-18 15:10:30 PDT
No problem anymore with 2006-04-18 trunk build on windows. All testcases are WFM. Fixed by bug 287813.
Comment 49 Stephen Donner [:stephend] 2006-04-28 09:41:40 PDT
Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP.
Comment 50 dapowell 2006-05-23 06:03:14 PDT
For a simple fix, without the need for real javascript.

In CSS you can use:

position:fixed;
position:expression("absolute");

Mozilla will use fixed and work correctly, IE will use absolute and work correctly. I know its a hack, but this will work for Mozilla and IE, until things are fixed in Mozilla and publicly released.

This was tested on IE 6.0 and Firefox 1.5
Comment 51 Ganesh Ravindran 2006-05-24 01:42:56 PDT
As has been detailed already, it is caused by the css attribute/value "overflow: auto;".

If the css attribute is split as "overflow-x: auto; overflow-y: auto", this issue doesn't seem to appear.
Comment 52 dapowell 2006-05-30 06:51:48 PDT
(In reply to comment #51)
> As has been detailed already, it is caused by the css attribute/value
> "overflow: auto;".
> 
> If the css attribute is split as "overflow-x: auto; overflow-y: auto", this
> issue doesn't seem to appear.
> 

Actually this solution does not work if you want an absolutely position div with overflow of visible or simply not setting the overflow. "overflow-x: visible; overflow-y: visible" will still not show the cursor.
Comment 53 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-05-30 14:36:00 PDT
(In reply to comment #51)
> As has been detailed already, it is caused by the css attribute/value
> "overflow: auto;".
> 
> If the css attribute is split as "overflow-x: auto; overflow-y: auto", this
> issue doesn't seem to appear.

I don't believe this. The latter is *exactly* the same as the former.

Comment 54 Darin Fisher 2006-06-26 11:33:11 PDT
Not going to block FF2 for this.  Sounds like it'd be a high-risk fix if anything.  We'd still welcome a safe patch if one appears.
Comment 55 Sam Gross 2006-07-13 07:41:42 PDT
I am not familiar with Mozilla's bug tracking system, but why is this bug "verified fixed"? It's not fixed on Firefox 2.0 beta 1 or Firefox 1.5.

For example https://bugzilla.mozilla.org/attachment.cgi?id=99019 fails.
Comment 56 Martijn Wargers [:mwargers] (not working for Mozilla) 2006-07-13 07:44:55 PDT
Sam, it's fixed on trunk builds, not on branch builds.
Trunk builds you can download here:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk
Branch builds you can download here:
ftp://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-mozilla1.8
Comment 57 dan24678 2006-07-14 12:54:27 PDT
I have experienced this bug using a combination of positioned DIVs and also toggling display on an input element. Definitely some irony here that trying to use a tableless layout actually makes things harder for you and makes your application frustrating to FF users.

As previously mentioned, this bug is a major hassle when developing AJAX/DHTML apps. I've tried adding "overflow: auto" to fix it, to no avail.  This is the first time I've ever posted or been seriously limited by a FF bug. To me, as a developer, fixing this bug in FF 1.5 is more important than any new features you might add in future releases. I've never been so frustrated by a browser bug (including IE!!).

Can you please give me some specifics as far as when this fix will begin being available to users downloading FF from the public site?  And is it really "fxied" for all possible causes?  I need to know if I can safely ignore this or if I need to convert my whole page to a table layout. 
Comment 58 dan24678 2006-07-14 13:07:05 PDT
Actually, right after I posted this, I found a fix that worked for the display: none issue. Sometimes, if you hide an element which has focus (nested in a div), it takes the caret with it and you can't get it back. BUT if you make sure to focus() something else first, you won't lose the caret.
Comment 59 Ryan Flint [:rflint] (ping via IRC for reviews) 2006-08-18 14:12:29 PDT
*** Bug 349237 has been marked as a duplicate of this bug. ***
Comment 60 Ryan Flint [:rflint] (ping via IRC for reviews) 2006-08-18 14:16:12 PDT
*** Bug 349238 has been marked as a duplicate of this bug. ***
Comment 61 Scott Simpson 2006-08-18 15:39:26 PDT
by reordering the elements i was able to have the cursor appear in the correct fashon.  i simply placed the problem causing DIV at the top, ahead of all of the rest of the display HTML.  seems to have worked.

I'm pretty displeased with FF for having and continuing to have a bug like this.  While it is fixed in the trunk build...perhaps fixing it in 1.5.0.6 and releasing an update would be really appreciated by the community, especially those of us doing AJAX work.
Comment 62 Daniel Fazza 2006-09-29 06:36:01 PDT
Please dan24678@yahoo.com an everybody, post the testcase and workaround for us!
You wrote: focus() something else before hidden the div. How? with javascript?

If yes, ok, but if the page have more than one div and inputs, this will be very unpleased.

(In reply to comment #58)
> Actually, right after I posted this, I found a fix that worked for the display:
> none issue. Sometimes, if you hide an element which has focus (nested in a
> div), it takes the caret with it and you can't get it back. BUT if you make
> sure to focus() something else first, you won't lose the caret.
> 
Comment 63 Daniel Fazza 2006-09-29 14:05:46 PDT
I can't believe! I was install Firefox 2.0 Beta Bon Echo and this bug still there! After four years! this bug was first reported at september 2002! 
My menu-bar with css can't work, none workarounds fix it!
Comment 64 Wayne Mery (:wsmwk, NI for questions) 2006-10-05 17:53:38 PDT
*** Bug 293749 has been marked as a duplicate of this bug. ***
Comment 65 Paul Raines 2006-10-17 11:37:36 PDT
My workaround is to not use visibility but just push things off screen.
See the difference between:

http://www.nmr.mgh.harvard.edu/~raines/view.html

http://www.nmr.mgh.harvard.edu/~raines/view2.html
Comment 66 Ben Bucksch (:BenB) 2006-10-17 11:53:34 PDT
raines, you're not setting the focus at all, as far as I could see. I don't think this is the same problem.
Comment 67 Paul Raines 2006-10-17 12:15:48 PDT
The problem is not about focus.  It is about overlapping DIVs and
the affect on the cursor in input text fields.  As my first
web page shows.
Comment 68 Danil Ilinykh 2006-10-27 01:37:50 PDT
*** Bug 358322 has been marked as a duplicate of this bug. ***
Comment 69 Anders Conbere 2006-11-03 13:24:53 PST
*** Bug 359439 has been marked as a duplicate of this bug. ***
Comment 70 Ria Klaassen (not reading all bugmail) 2006-11-10 07:17:49 PST
*** Bug 360253 has been marked as a duplicate of this bug. ***
Comment 71 atencza 2006-11-15 13:58:45 PST
I am seeing this issue in Firefox 1.5 and 2.0. It is extremely annoying! The workarounds are undesirable. Please reopen bug.
Comment 72 Edemilson Lima 2006-11-16 11:14:08 PST
Created attachment 245770 [details]
z-Index testcase

I have made many tests using DIVs and text boxes in Firefox and I discover that the z-index for each DIV must match the same order of the DIVs in the document or the caret cursor will not show when they overlap. I am using Javascript to create DIVs to act like popups, where z-index is changed dinamically. In this case the only workaround I found was changing the DIV overflow property to 'hidden' with an onmouseout event and to auto with an onmouseover. I must do the same when showing or hidding DIVs.
Comment 73 tobias 2006-12-05 01:31:27 PST
Created attachment 247519 [details]
the cursor in the text-box disappears over an iframe.

setting the z-index does not work here.
Comment 74 Stephen Donner [:stephend] 2006-12-05 06:53:07 PST
(In reply to comment #73)
> Created an attachment (id=247519) [edit]
> the cursor in the text-box disappears over an iframe.
> 
> setting the z-index does not work here. 

In _which_ build? 
Comment 75 tobias 2006-12-05 06:58:55 PST
Comment on attachment 247519 [details]
the cursor in the text-box disappears over an iframe.

firefox version 2.0
Comment 76 Ryan VanderMeulen [:RyanVM] 2006-12-05 07:00:51 PST
This bug was fixed on the trunk (which is leading to Firefox 3.0). It wasn't fixed for version 2.0.
Comment 77 Robert O'Callahan (:roc) (email my personal email if necessary) 2006-12-06 20:03:09 PST
*** Bug 362883 has been marked as a duplicate of this bug. ***
Comment 78 Ria Klaassen (not reading all bugmail) 2006-12-20 08:58:49 PST
*** Bug 364480 has been marked as a duplicate of this bug. ***
Comment 79 Ria Klaassen (not reading all bugmail) 2006-12-21 23:58:22 PST
*** Bug 364669 has been marked as a duplicate of this bug. ***
Comment 80 Eric Popivker 2007-02-21 05:40:14 PST
Is the bug fix going to be released on any updates for version 2.0 or only when 3.0 comes out?

I am developing generic popup DIV which should be able to appear in front of any other DIV in the background, so current workarounds don't work.
Comment 81 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-02-21 05:48:15 PST
Only when firefox 3.0 comes out. The bug fix depends on all kind of other bug fixes that only happened on trunk.
Comment 82 Chris Barlow 2007-02-22 08:52:32 PST
I came across the same problem with a missing cursor in an ajax/tabbed pages situation (FF 1.5 and 2.0).  I am using overflow:auto, but the problem seemed to stem more from an absolutely positioned div within another absolutely positioned div.  Here is a simplified example using inline styles where I experienced the problem and my fix below.

<div style="position:absolute;">
	<div id="p1" style="position:absolute;overflow:auto;">form</div>
	<div id="p2" style="position:absolute;overflow:auto;">form</div>
</div>

My fix was to change p1 and p2 to position:relative and add display:none.  Then in javascript, set just the selected page to display:block and the page being unselected to display:none.

This probably won't fix everyone's problem, but I hope it helps a few people until FF 3.0 is released.
Comment 83 Marcel 2007-03-19 04:36:21 PDT
I am also using input boxes in deeply (tabpages) nested absolute div's, where sometimes the carret disappears.
Because none of the fixes work for me, where using position:fixed being the most horrific one, i just keep on trying.

for me this works (only tested it on FF2.0):
<div style="position:absolute;display:block;"><div style="width:1px;"><input type="text"/></div></div>

hope it helps.

And as others allready pointed out, its pretty sad it takes more then 4 years to fix a bug, any bug, even one as bad as this one.
Comment 84 Brian Sullivan 2007-03-20 12:25:15 PDT
Thanks to all of the work above, I isolated the key fixes that seem to be essential.  I have a complex set of potentially overlapping popup divs whose operation was fixed by the following combination:

#1 You need to wrap the text elements with a div like whose style is overflow:auto. I use this as the outermost div of my draggable popup window:

<div id="popupWin" class="popupFrame" style="overflow:auto;">

#2 You need to set the div display none, delay, and set the div display to block

//get the div
var d = document.getElementById('popupWin');
// set div display to none
d.style.display = 'none';
// setTimeout to a function and bind the div to it
setTimeout(setElDisplayBlock.bind(p),10);

// in this function, the div has been bound so it will be referenced as 'this'
function setElDisplayBlock(){
	this.style.display = 'block';
}

If you always know the id of your div, you don't need to bind the div to the function in the setTimeout, but you do need a delay before setting display=block

Thanks again for all of the help
Comment 85 Vlad 2007-05-02 02:06:24 PDT
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.3) Gecko/20070309 Firefox/2.0.0.3

Cursor disappears from input field. We can type any text in this field, but
never can see cursor in it:
<div style="height:50%;width:50%;overflow:auto">
<div style="position:absolute;"><input type=text name="1"></div>
</div>


Reproducible: Always

Steps to Reproduce:
1. Click in the input field.


Expected Results:  
Normaly we may see cursor blinking but it not happen on this page:(

With this code we can repoduce this bug.
<div style="height:50%;width:50%;overflow:auto">
<div style="position:absolute;"><input type=text name="1"></div>
</div>
But if we remove
overflow:auto;
and/or
position:absolute;
All works perfectly.
Comment 86 Ralf Vitasek 2007-05-10 01:15:05 PDT
since many of the provided tescases still show the buggy behavior i don't think this is really fixed.

please verify again, thanks!

Comment 87 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-05-10 01:22:36 PDT
Ralf, did you test with a nightly trunk build?
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-trunk/
It's not useful to test, unless you use a nightly trunk build.
Comment 88 Ralf Vitasek 2007-05-10 05:58:54 PDT
hmm fixed on "2006-04-28-05" i expected that to be already in FF2.

a bit hard to grasp without knowing the date when FF2 branched.
Comment 89 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-05-10 06:30:53 PDT
FF2 branched on 2005-08-12.
See http://developer.mozilla.org/en/docs/CVS_Tags
Comment 90 Carsten Book [:Tomcat] 2007-05-24 15:43:48 PDT
*** Bug 381928 has been marked as a duplicate of this bug. ***
Comment 91 GAVIN BRYAN 2007-06-11 16:17:03 PDT
I've hit this problem now and did some searches on google as I suspected this was a browser bug and it finally brought me to this page. I've read the emails from 2002 to recently and am confused as to if this is fixed or not in some version of FF out there (I'm using 2.0.0.4 and is not working so ossibly the fix might be pre-release if that is the terminology here). Could someone explain in plain English the following please as I'm new here :-

1. Has the bug been fixed ?
2. If it has been fixed is it likely to be in a public release sometime soon ?
3. If it has been fixed will it be applied as a patch ?

I ask as am developing an Ajax management app with modal popups with data entry screens with splitter screens and whole app fails due to the above. If it's not likely to be fixed in a public version I will have to consider a different design. I can't get any of the workarounds to work.

Many Thanks
Comment 92 Ryan VanderMeulen [:RyanVM] 2007-06-11 16:21:56 PDT
This is fixed on the Gecko 1.9 trunk, which is what will become the backend for Firefox 3.0 once it's released.
Comment 93 anthony tippett 2007-08-08 14:06:41 PDT
I was able to workaround by not using the visibility style but instead use the block: none and so forth.

The caret gets hidden by a div that has it's visibility set to hidden.
Comment 94 Boris Zbarsky [:bz] (still a bit busy) 2007-08-10 21:43:39 PDT
*** Bug 387449 has been marked as a duplicate of this bug. ***
Comment 95 diefans 2007-08-23 09:15:02 PDT
when I remove "overflow: auto;" from the body, 
but keeping it in the containing div of the input or textarea then it works for me.

i use FF 2.0.0.6 on ubuntu
Comment 96 Anders Both 2007-09-04 15:51:57 PDT
Workaround Gecko/20070725 Firefox/2.0.0.6 : 

Changing position-style from absolute to fixed (for Gecko only) for the Div contaning the textbox, worked for me.

Comment 97 Hans Castorp 2007-10-15 10:47:55 PDT
I think i have foun the easiest workaround:

document.getElementById("input").focus();

For example on the onclick() event...
Comment 98 Hans Castorp 2007-10-15 10:48:33 PDT
I think i have found the easiest workaround:

document.getElementById("input").focus();

For example on the onclick() event...
Comment 99 Alejandro Torras 2007-10-24 05:18:35 PDT
Hi,

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.8) Gecko/20071008 Firefox/2.0.0.8

The problem persists: DIV style="visibility: hidden" above the affected INPUT type="text" hiddens the caret.

Solution: change visibility to display as pointed in comment #93

Pointed here by: http://www.bram.us/2007/05/31/my-note-to-myself-dissapearing-firefox-caret-cursor-css-fix/

Should this bug be reopened?

Regards.
Comment 100 Martijn Wargers [:mwargers] (not working for Mozilla) 2007-10-24 05:30:13 PDT
(In reply to comment #99)
> Should this bug be reopened?

no, because this bug is fixed on trunk.
It is known that it is still a problem on branch, but there isn't really anything that can be done about that. The patch that fixed this is almost impossible to backport to the branch.
Comment 101 Kyle White 2007-11-06 07:30:06 PST
Does it take 2 years to merge this fix?

The fact is, a painting bug fix will have no repercussions on any existing sites, because it would be impossible to rely on it.  You certainly don't even have to be a programmer to know that.  So why exactly is this bug fix not merged yet?  I only wish for a better Firefox.

Comment 102 Steve 2007-11-06 08:26:55 PST
It is rather annoying that this hasn't been pushed a bit faster up the tree.

I didn't see anything in the comments for this, but if there is a JavaScript trick to make it re-appear in the meantime, I would certainly like to know what it is.  I can't change my CSS display properties, but I can hook in all the JS I can shake a stick at! ;-)

thanks
Comment 103 Ryan VanderMeulen [:RyanVM] 2007-11-06 08:32:43 PST
What about comment #100 is unclear? The fix is on the trunk and relies heavily on other changes which were made on the trunk as well in order to work. Backporting it to Fx2 isn't going to happen because it would require way too much developer energy and be extremely regression prone. Plain and simple, it's not worth the resources when Fx3 is already nearing its first beta release.

I know you guys aren't happy with the situation, but that's the way it is.  The fix is in what will eventually become Fx3.

In the future, please follow the etiquette guidelines before deciding to spam bugs with yet another "me too" comment and forcing everybody who's CCed to it to read your thoughts on the matter. I assure you that most of us on the CC list really don't want to hear them.
https://bugzilla.mozilla.org/page.cgi?id=etiquette.html
Comment 104 rajeswaran 2007-12-19 23:05:00 PST
Created attachment 294001 [details]
 the cursor in the text-box disappears over an iframe.(fixed)

the cursor in the text-box appear over an iframe.

div Apply the style overflow:auto;
Comment 105 PVOID 2008-03-10 09:18:38 PDT
> the cursor in the text-box appear over an iframe.
> div Apply the style overflow:auto;

Switching display propetry of an iframe comtainer or iframe makes caret bug return even if overflow:auto present
Comment 106 scragz 2008-03-22 11:41:01 PDT
I'm getting this in Gmail when replying to people (not with normal compose) with Firefox 3 beta 4.
Comment 107 Brett Leber 2008-04-11 07:31:44 PDT
I cannot find a suitable workaround for the case where the div underneath has position:fixed. That is, if you modify "z-Index testcase" so that the bottom-most div has position:fixed, no workaround seems to work.
Comment 108 Mats Palmgren (:mats) 2008-06-06 12:07:39 PDT
*** Bug 437595 has been marked as a duplicate of this bug. ***
Comment 109 Sheldon Glickler 2008-06-23 04:49:39 PDT
I am using FF 2.0.0.14.  I have encountered this bug.  I am somewhat confused by the possible workarounds.  Here is my situation.  I have a popup block that MUST use position:fixed.  The customer wants it to appear at the same part of the screen regardless of the scrolling.  There are three such popups.  They are all given visibility:hidden.  The reason for this is to not push the rest of the screen down that is behind the popup.  I have the z-index changed to 99 when dynamically changing the visibility to visible.  Originally it is set at -1.  The reason I did that was because some buttons were not being activated when clicked because they were hidden behind this hidden block.  The block has both a textarea and a text field.  Neither one shows focus (caret?) when clicked, but both accept text.  

This is an AJAX/DHTML application.  I am using overflow:hidden in the mainwrapper surrounding everything including this div.  I have IE6 code that sets overflow-x:auto and overflow-y:hidden.  

What can I do to make this work?
Comment 110 Matt 2008-08-07 09:03:20 PDT
This bug reveals a problem in Mozilla post-release bug fixing. We have been made to wait 6 years for this bug to be fixed.

As this affects production applications, which could have been run on Firefox but likely were forced to require IE, it should be clear to Mozilla that this kind of bug is a production patch worthy because of the severity of the issue.

What has effectively happened is the browser has been unuseable for the best of the new breed of web applications because Mozilla didn't feel this was severe enough to release a production patch for.

Mozilla, you have wasted 6 years of potential market gains in the high growth area of web 2.0 applications.

I hope it's clear your patch policies should change because of this bug.
Comment 111 Dan Nye 2008-10-19 05:48:40 PDT
(In reply to comment #107)
> I cannot find a suitable workaround for the case where the div underneath has
> position:fixed. That is, if you modify "z-Index testcase" so that the
> bottom-most div has position:fixed, no workaround seems to work.

Brett,

I've been having the same issue as you, and none of the other workarounds seem to work in this case.

I've finally come up with a JavaScript solution, which I've posted here:

http://www.codecouch.com/2008/10/fixing-a-disappearing-caret-in-firefox/

Note, that it does cause Firefox to produce rendering errors on scrolling (!) if your fixed element has a background image, but that might not be an issue in your case.
Comment 112 Mariusz Nowak 2009-06-03 03:37:47 PDT
I've had this problem in FF3 but this time not related to iframe or overflow setting but because of disabling input for a moment.

If someone stumbles upon same issue, this may help:

Testcase to reproduce problem:
textarea.disabled = true;
setTimeout(function() {
  textarea.disabled = false;
  textarea.focus();
}, 0);

How to fix it:
textarea.blur(); // blur first
textarea.disabled = true;
setTimeout(function() {
  textarea.disabled = false;
  textarea.focus();
}, 0);
Comment 113 Daniel LaLiberte 2010-07-30 14:38:44 PDT
I'm working on a project that requires use of Firefox 2.0.0.1 (with XUL as well), and we were experiencing this problem of the disappearing caret.  None of the workarounds suggested here were working for me.  

What made the problem particularly confusing for us was that the problematic elements missing the overflow:auto were in other invisible absolutely positioned dialogs, hidden using visibility:hidden.  Once we figured that out, it was a simple matter to switch to using display:none instead.

Note You need to log in before you can comment on or make changes to this bug.