Firefox cursor disappear in beginning of text fields

Bug #164526 reported by Marc K. on 2007-11-22
6
Affects Status Importance Assigned to Milestone
Mozilla Firefox
Fix Released
Medium
firefox-3.0 (Ubuntu)
Medium
Unassigned

Bug Description

I have some javascript code that displays a custom "dialog" box, that is, a DIV on top of a disabled DIV on top of the page (so as to create the effect of a modal dialog box). The "dialog" has a number of text fields.

When I click on any text field to enter some text, the cursor (displayed as a bar) does not show starting from the beginning of the text until a number of characters. Afterwards it shows again normally.

Example: xxxxxABCD cursor shows up again after the last x.

In some fields, I can only see a tiny part of the cursor. It gives the appearance as if the cursor coordinate is miscalculated.

Additional information:
- Gutsy Gibbon (Ubuntu 7.10)
- Firefox 2.0.0.8
- Motherboard ASUS P5LD2-X with Intel Core Duo @ 2GHz
- Video card ATI Radeon
- Monitor ViewSonic E50cSB but detected as Plug n Play, 1024x768

Please let me know if you need more information.
Thanks.

Created attachment 98624
This sample illustrates the behavior where the cursor sometimes fails to appear in input text fields.

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.

Created attachment 99019
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?

Created attachment 125003
workaround

Here's a version of attachment 99019 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. ***

*** 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.

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.

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

Created attachment 187105
Another simple testcase (caret partialy showed)

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

Created attachment 190975
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.

*** 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

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.

Created attachment 203423
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.

Created attachment 203425
Simple Tabbed View showing workaround

Same Tabbed View as above, but showing workaround where DIV's are replaced with TABLES

Created attachment 205135
Cursor is not shown even when the DIV is hidden

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

(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.

39 comments hidden view all 119 comments

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!

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.

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.

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

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.

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

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

In , Anbo (anbo) wrote :

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

Marc K. (marc-centrin) wrote :

I have some javascript code that displays a custom "dialog" box, that is, a DIV on top of a disabled DIV on top of the page (so as to create the effect of a modal dialog box). The "dialog" has a number of text fields.

When I click on any text field to enter some text, the cursor (displayed as a bar) does not show starting from the beginning of the text until a number of characters. Afterwards it shows again normally.

Example: xxxxxABCD cursor shows up again after the last x.

In some fields, I can only see a tiny part of the cursor. It gives the appearance as if the cursor coordinate is miscalculated.

Additional information:
- Gutsy Gibbon (Ubuntu 7.10)
- Firefox 2.0.0.8
- Motherboard ASUS P5LD2-X with Intel Core Duo @ 2GHz
- Video card ATI Radeon
- Monitor ViewSonic E50cSB but detected as Plug n Play, 1024x768

Please let me know if you need more information.
Thanks.

Created attachment 294001
 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;

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

John Vivirito (gnomefreak) wrote :

Sorry but Firefox-2 is getting near EOS and they wont be fixing anything but major issues security issues mainly. Please try to reproduce this with Firefox-3.0 if you can reproduce this bug please click on Help > Report a problem and file the bug that way. This does not mean that it wasn't already fixed.

Changed in firefox:
status: New → Won't Fix

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

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.

crackie (nomedsoft) wrote :

This bug seems to be FireFox related coz it also happens in Windows as you can read by following the link:

http://www.fixya.com/support/t1361531-missing_cursor_firefox

hope that helps

crackie (nomedsoft) wrote :

if the above link fails read here:
 https://bugzilla.mozilla.org/show_bug.cgi?id=167801

affects: firefox (Ubuntu) → firefox-3.0 (Ubuntu)
Changed in firefox-3.0 (Ubuntu):
status: Won't Fix → Confirmed
Marc K. (marc-centrin) wrote :

Sorry for the late report. I just had an email about this bug today. Anyway, I have switched to Firefox 3 since a couple of months ago and this problem is gone.

Changed in firefox:
status: Unknown → Fix Released
Changed in firefox-3.0 (Ubuntu):
importance: Undecided → Medium
status: Confirmed → Triaged

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);

Micah Gersten (micahg) wrote :

This seems to have been released with the initial release of Firefox 3.0 a while ago.

Changed in firefox-3.0 (Ubuntu):
status: Triaged → Fix Released

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.

Changed in firefox:
importance: Unknown → Medium
Displaying first 40 and last 40 comments. View all 119 comments or add a comment.
This report contains Public information  Edit
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.