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

RESOLVED FIXED

Status

()

Core
Selection
RESOLVED FIXED
15 years ago
7 years ago

People

(Reporter: Bill Walsh, Assigned: mrbkap)

Tracking

({testcase})

Trunk
testcase
Points:
---
Dependency tree / graph
Bug Flags:
blocking1.8.1 -

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(11 attachments)

(Reporter)

Description

15 years ago
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.
(Reporter)

Comment 1

15 years ago
Created attachment 98624 [details]
This sample illustrates the behavior where the cursor sometimes fails to appear in input text fields.
(Reporter)

Comment 2

15 years ago
This bug seems to be similar to the behavior described in bugs #143777 and 
#144419.

Comment 3

15 years ago
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
Created attachment 99019 [details]
simpler testcase
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?

Updated

15 years ago
Keywords: testcase
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

14 years ago
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

14 years ago
*** 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. ***

Comment 13

13 years ago
*** Bug 272577 has been marked as a duplicate of this bug. ***
Blocks: 188517, 218642
*** Bug 279198 has been marked as a duplicate of this bug. ***
*** Bug 283044 has been marked as a duplicate of this bug. ***

Comment 16

12 years ago
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.

Updated

12 years ago
Blocks: 282358

Comment 17

12 years ago
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.

Updated

12 years ago
Blocks: 295838
Blocks: 293749

Comment 19

12 years ago
*** Bug 223239 has been marked as a duplicate of this bug. ***

Comment 20

12 years ago
Created attachment 187105 [details]
Another simple testcase (caret partialy showed)

Comment 21

12 years ago
*** Bug 298615 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Blocks: 226933

Comment 22

12 years ago
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

12 years ago
*** Bug 298454 has been marked as a duplicate of this bug. ***
*** Bug 258345 has been marked as a duplicate of this bug. ***

Comment 25

12 years ago
(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

12 years ago
*** Bug 308151 has been marked as a duplicate of this bug. ***

Comment 27

12 years ago
*** 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

Comment 29

12 years ago
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.

Comment 32

12 years ago
(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.

Updated

12 years ago
Assignee: selection → mrbkap

Comment 34

12 years ago
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

12 years ago
Created attachment 203425 [details]
Simple Tabbed View showing workaround

Same Tabbed View as above, but showing workaround where DIV's are replaced with TABLES
No longer blocks: 295838
Blocks: 230701
No longer blocks: 282358

Comment 36

12 years ago
Created attachment 205135 [details]
Cursor is not shown even when the DIV is hidden

Comment 37

12 years ago
*** Bug 322130 has been marked as a duplicate of this bug. ***

Updated

12 years ago
Depends on: 287813

Comment 38

12 years ago
(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?

Comment 40

12 years ago
(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

12 years ago
Is this related to https://bugzilla.mozilla.org/show_bug.cgi?id=226933

Updated

12 years ago
Flags: blocking1.9a1?

Updated

12 years ago
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 :-)

Comment 43

11 years ago
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
Last Resolved: 11 years ago
Resolution: --- → FIXED
Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP.
Status: RESOLVED → VERIFIED

Comment 50

11 years ago
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

11 years ago
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

11 years ago
(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.

Comment 54

11 years ago
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-

Comment 55

11 years ago
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

Comment 57

11 years ago
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

11 years ago
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. ***

Comment 61

11 years ago
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

11 years ago
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

11 years ago
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

Comment 65

11 years ago
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

11 years ago
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

11 years ago
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

11 years ago
*** Bug 358322 has been marked as a duplicate of this bug. ***

Comment 69

11 years ago
*** Bug 359439 has been marked as a duplicate of this bug. ***
*** Bug 360253 has been marked as a duplicate of this bug. ***

Comment 71

11 years ago
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

11 years ago
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

11 years ago
Created attachment 247519 [details]
the cursor in the text-box disappears over an iframe.

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 75

11 years ago
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. ***

Comment 80

10 years ago
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.

Comment 82

10 years ago
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

10 years ago
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

10 years ago
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

10 years ago
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

10 years ago
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
Last Resolved: 11 years ago10 years ago
Resolution: --- → FIXED

Comment 88

10 years ago
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

Updated

10 years ago
Duplicate of this bug: 381928

Comment 91

10 years ago
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.

Comment 93

10 years ago
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.
Duplicate of this bug: 387449

Comment 95

10 years ago
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

10 years ago
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

10 years ago
I think i have foun the easiest workaround:

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

For example on the onclick() event...

Comment 98

10 years ago
I think i have found the easiest workaround:

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

For example on the onclick() event...

Comment 99

10 years ago
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.

Comment 101

10 years ago
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

10 years ago
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

Comment 104

10 years ago
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

9 years ago
> 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

9 years ago
I'm getting this in Gmail when replying to people (not with normal compose) with Firefox 3 beta 4.

Comment 107

9 years ago
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.

Updated

9 years ago
Duplicate of this bug: 437595

Comment 109

9 years ago
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

9 years ago
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

9 years ago
(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

8 years ago
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

7 years ago
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.

Updated

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