230701 - The cursor (caret) in a text input turns invisible when it is over a fixed element.

Status: VERIFIED FIXED

(Core :: Layout: Form Controls, defect)

Description

[Eric Jacobsen]

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040111
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7a) Gecko/20040111

When an block containing text inputs (using absolute positioning) is placed over
another element that has fixed positioning, the I-bar cursor in the input boxes
is invisible while it is over the fixed container.

Reproducible: Always

Steps to Reproduce:
1. Create a box (div) containing some text input boxes. Give the box a style
something like this: {position:absolute; z-index:99; top:0px; left:0px;
width:100px; height:200px;}
2. Create another box with fixed positioning, something like this:
{position:fixed; z-index:50; top:0px; left:0px; width:100px; height:200px;
overflow:none;}
3. Place a large image or something in the fixed box.
Actual Results:  
4. Click on a text input that is over the fixed box; the I-bar cursor will be
invisible.
5. If you have any text inputs that are not over the fixed box, the blinking
I-bar will be visible in those inputs. If you have an input that is half-over
the fixed input, the cursor will be partially visible.

Expected Results:  
The cursor ought to be visible as long as it's in a container with the highest
z-index value.

Comment 1

[José Jeria]

This looks/behaves a bit like bug 226933, though that one is with an iframe.

Comment 2

[Boris Zbarsky [:bzbarsky]]

Same problem, really -- fixed pos elements have native widgets too.

Comment 3

[Brandon Amedee]

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a2) Gecko/20040523

I'm having the exact same problem.

I've noticed though that I have a fixed div, positioned over a fixed background
div, and the i-bar works just fine.  Another text input in an absolute
positioned div doesn't display an i-bar though. You can see both of these
instances in a testcase at http://exonyte.dyndns.org/testcase/230701/

Comment 4

[Martijn Wargers (dead)]

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

Comment 5

[:Gavin Sharp [email: [e-mail]]]

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

Comment 6

[:Gavin Sharp [email: [e-mail]]]

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

Comment 7

[Samuel Sieb]

Attachment: simple demonstration of the invisible cursor

The original behaviour was that the cursor would only show up in the hidden text field when it was shown.  The new behaviour (after the display list changes) is that the cursor shows up in the non-hidden text field and won't show in the hidden one when it is shown.  Note that the focus is actually there (you can type).

Comment 8

[Samuel Sieb]

I'm testing this on Linux.

Comment 9

[Claudiu Cismaru]

The same caret behavior is in the next situation:

<div id="1" style="position: absolute; width: 300px; height: 300px">
  <div id="2" style="position: absolute; width: 100px; height: 100px; overflow: auto;">
  </div>
  <div id="3" style="position: absolute;">
    <input id="problematic_input" type="text" />
  </div>
</div>

The caret disappear when the div element with id 2 has overflow: auto OR overflow: scroll specified.

Comment 10

[:Gavin Sharp [email: [e-mail]]]

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

Comment 11

[Martijn Wargers (dead)]

No problem anymore with 2006-04-18 trunk build on windows. Testcase is worksforme now. Fixed by bug 287813.

Comment 12

[Stephen Donner [:stephend] Not actively reading bugmail]

Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP.

Comment 13

[Clint Hall]

If this bug is fixed, why are we not seeing the testcases work in Firefox 2.0 RC2?  Am I missing something regarding how fixes in Core reach the Firefox pipeline?

Comment 14

[Martijn Wargers (dead)]

It is fixed on trunk, in this case it means this will be fixed in Firefox3.0.

Comment 15

[rosen]

this bug has been fixed a year ago now but the current version still does not contain this fix. isn't it possible to merge this bugfix into the next 2.0.x.x-Version?

Comment 16

[Martijn Wargers (dead)]

No, the patch that fixed it (bug 287813) was very complicated and caused some regressions.
Also, it depended on an even larger and more complicated patch.
Merging it back is too risky.

Comment 17

[Dan Nye]

For those people wanting a potential fix that doesn't involve upgrading to Firefox 3, I've come up with a JavaScript solution, which I've posted here:

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

I say 'potential' because if your fixed element has a background image, then Firefox will produce rendering errors on scrolling (!), so it might not be suitable for every usage.