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

VERIFIED FIXED

Status

()

VERIFIED FIXED
15 years ago
10 years ago

People

(Reporter: eric, Unassigned)

Tracking

Trunk
Points:
---
Dependency tree / graph

Firefox Tracking Flags

(Not tracked)

Details

(URL)

Attachments

(1 attachment)

(Reporter)

Description

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

15 years ago
This looks/behaves a bit like bug 226933, though that one is with an iframe.
Same problem, really -- fixed pos elements have native widgets too.
Depends on: 226933

Comment 3

14 years ago
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/
Product: Browser → Seamonkey
Assignee: general → nobody
Component: General → Layout: Form Controls
Product: Mozilla Application Suite → Core
QA Contact: general → layout.form-controls
*** Bug 305783 has been marked as a duplicate of this bug. ***
Depends on: 287813

Updated

13 years ago
Summary: The cursor in a text input turns invisible when it is over a fixed element. → The cursor (caret) in a text input turns invisible when it is over a fixed element.
*** Bug 295838 has been marked as a duplicate of this bug. ***
Depends on: 167801
No longer depends on: 226933
*** Bug 282358 has been marked as a duplicate of this bug. ***

Comment 7

13 years ago
Created attachment 211463 [details]
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

13 years ago
I'm testing this on Linux.
OS: Windows 2000 → All
Hardware: PC → All

Comment 9

13 years ago
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.
*** Bug 330810 has been marked as a duplicate of this bug. ***
No problem anymore with 2006-04-18 trunk build on windows. Testcase is worksforme now. Fixed by bug 287813.
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → FIXED
Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk under Windows XP.
Status: RESOLVED → VERIFIED

Comment 13

12 years ago
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?
It is fixed on trunk, in this case it means this will be fixed in Firefox3.0.

Comment 15

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

10 years ago
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.
You need to log in before you can comment on or make changes to this bug.