Closed Bug 167801 Opened 22 years ago Closed 17 years ago

Cursor (caret) sometimes fails to appear in input text fields (shown/painted in wrong widget)

Categories

(Core :: DOM: Selection, defect)

defect
Not set
normal

Tracking

()

RESOLVED FIXED

People

(Reporter: bill.walsh, Assigned: mrbkap)

References

Details

(Keywords: testcase)

Attachments

(11 files)

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.
This bug seems to be similar to the behavior described in bugs #143777 and 
#144419.
Excellent testcase.  -> selection, I suspect, though Roc may have some theories
here.
Assignee: jkeiser → mjudge
Status: UNCONFIRMED → NEW
Component: HTML Form Controls → Selection
Ever confirmed: true
QA Contact: tpreston → pmac
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?
Keywords: testcase
Attached file 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.
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
*** Bug 216353 has been marked as a duplicate of this bug. ***
*** Bug 237298 has been marked as a duplicate of this bug. ***
*** Bug 212732 has been marked as a duplicate of this bug. ***
*** Bug 210535 has been marked as a duplicate of this bug. ***
Blocks: 58359
Summary: Cursor sometimes fails to appear in input text fields. → Cursor (caret) sometimes fails to appear in input text fields (shown/painted in wrong widget)
Blocks: 257443
*** Bug 256020 has been marked as a duplicate of this bug. ***
*** Bug 272577 has been marked as a duplicate of this bug. ***
*** Bug 279198 has been marked as a duplicate of this bug. ***
*** Bug 283044 has been marked as a duplicate of this bug. ***
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.
Blocks: 282358
Is this bug in the realm of being considered?
mrbkap is working on a fix but it won't make 1.8/FF 1.1.
Blocks: 295838
Blocks: 293749
*** Bug 223239 has been marked as a duplicate of this bug. ***
*** Bug 298615 has been marked as a duplicate of this bug. ***
Blocks: 226933
I'm not sure whether this is relevant, but changing the input's position from
"absolute" to "fixed" causes the caret to appear.
*** Bug 298454 has been marked as a duplicate of this bug. ***
*** Bug 258345 has been marked as a duplicate of this bug. ***
(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.

*** Bug 308151 has been marked as a duplicate of this bug. ***
*** Bug 310490 has been marked as a duplicate of this bug. ***
We can reproduce this bug on Win/Linux/Mac(except Camino).

-> All/All
OS: Windows 2000 → All
Hardware: PC → All
Assignee: mjudge → selection
QA Contact: pmac
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!
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
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.
(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.
(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.
Assignee: selection → mrbkap
This is a simple Tabbed View interface showing the caret bug where the caret is invisible in the text fields of the first tab.
Same Tabbed View as above, but showing workaround where DIV's are replaced with TABLES
*** Bug 322130 has been marked as a duplicate of this bug. ***
Depends on: 287813
(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?
(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?
(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.
Flags: blocking1.9a1?
Flags: blocking1.9a1? → blocking1.8.1?
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 :-)
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>
*** Bug 329997 has been marked as a duplicate of this bug. ***
*** Bug 319394 has been marked as a duplicate of this bug. ***
No longer blocks: 218642
Optimistic blocker+, want to hear more about the branch approach ASAP though.
Flags: blocking1.8.1? → blocking1.8.1+
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.
No problem anymore with 2006-04-18 trunk build on windows. All testcases are WFM. Fixed by bug 287813.
Status: NEW → RESOLVED
Closed: 18 years ago
Resolution: --- → FIXED
Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP.
Status: RESOLVED → VERIFIED
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
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.
(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.
(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.

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.
Flags: blocking1.8.1+ → blocking1.8.1-
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.
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
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. 
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.
*** Bug 349237 has been marked as a duplicate of this bug. ***
*** Bug 349238 has been marked as a duplicate of this bug. ***
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.
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.
> 
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!
*** Bug 293749 has been marked as a duplicate of this bug. ***
No longer blocks: 293749
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
raines, you're not setting the focus at all, as far as I could see. I don't think this is the same problem.
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.
*** Bug 358322 has been marked as a duplicate of this bug. ***
*** Bug 359439 has been marked as a duplicate of this bug. ***
*** Bug 360253 has been marked as a duplicate of this bug. ***
I am seeing this issue in Firefox 1.5 and 2.0. It is extremely annoying! The workarounds are undesirable. Please reopen bug.
Attached file 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.
setting the z-index does not work here.
(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 on attachment 247519 [details]
the cursor in the text-box disappears over an iframe.

firefox version 2.0
This bug was fixed on the trunk (which is leading to Firefox 3.0). It wasn't fixed for version 2.0.
*** Bug 362883 has been marked as a duplicate of this bug. ***
*** Bug 364480 has been marked as a duplicate of this bug. ***
*** Bug 364669 has been marked as a duplicate of this bug. ***
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.
Only when firefox 3.0 comes out. The bug fix depends on all kind of other bug fixes that only happened on trunk.
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.
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.
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
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.
since many of the provided tescases still show the buggy behavior i don't think this is really fixed.

please verify again, thanks!

Status: VERIFIED → REOPENED
Resolution: FIXED → ---
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.
Status: REOPENED → RESOLVED
Closed: 18 years ago17 years ago
Resolution: --- → FIXED
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.
FF2 branched on 2005-08-12.
See http://developer.mozilla.org/en/docs/CVS_Tags
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
This is fixed on the Gecko 1.9 trunk, which is what will become the backend for Firefox 3.0 once it's released.
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.
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
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.

I think i have foun the easiest workaround:

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

For example on the onclick() event...
I think i have found the easiest workaround:

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

For example on the onclick() event...
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.
(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.
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.

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
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
the cursor in the text-box appear over an iframe.

div Apply the style overflow:auto;
> 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
I'm getting this in Gmail when replying to people (not with normal compose) with Firefox 3 beta 4.
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.
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?
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.
(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.
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);
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.
You need to log in before you can comment on or make changes to this bug.