8.84 KB, text/html
550 bytes, text/html
626 bytes, text/html
1.08 KB, text/html
161 bytes, text/html
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20031007 Firebird/0.7 in the page http://admin.competence-builder.com/divbug01.php when clicking on a table line a division is build with INPUT-elements - this division is on top of the layer containing the table. When focusing on the INPUT-elements the cursor position should be visible. In Mozilla and Firebird the cursor position is only visible when the lower division's style.overflow equals visible or hidden, not when it equals auto or scroll. Please check on the testing page by changing the style.overflow property any time in the selection field. Reproducible: Always Steps to Reproduce: 1. create a division with data and set style.overflow="auto" or "scroll" 2. create a second division with INPUT elements (type=text)on top(higher z-index) 3. focus on the INPUT elements Actual Results: cursor position is not visible Expected Results: blinking cursor position in he INPUT element being focused
Painting issue... If you can attach that test page to this bug using <http://bugzilla.mozilla.org/attachment.cgi?bugid=223239&action=enter> that would be great.
Assignee: general → roc
Status: UNCONFIRMED → NEW
Component: DOM HTML → Layout: View Rendering
Ever confirmed: true
OS: Windows XP → All
Hardware: PC → All
Summary: no cursor position when focusung on input/type=text and div with style.overflow=scroll or auto → no cursor position when focusing on input/type=text and div with style.overflow=scroll or auto
(this still occurs after bug 225811 was fixed)
The cursor of a simple input/text element disappeared after moved above the <div> with overflow set to auto/scroll. The same thing happen to <tbody> with overflow:auto or scroll.
If I may add a bit of information: this bug appears to involve the relationship between clipping of the cursor and scrollable areas. If you change the previous example to move the text box such that it is partially overlapping the underlying DIV, you will see that the cursor _does_ render partially (the part of it not overlapping the DIV). Notably, this bug is _not_ exhibited if the underlying DIV is instead a scrollable TEXTAREA. This should probably be a separate bug, but it seems worth noting that a text cursor _underneath_ an absolutely positioned DIV shows straight through it. I'm attaching a simple example that shows all of these cases. Has anyone else discovered a way to work around this? Hacks such as changing the underlying DIV's overflow style to 'hidden' might work for a single page, but for any kind of UI framework become rapidly infeasible. I've toyed with z-index, setting the underlying DIV to disabled, etc., to no avail.
*** Bug 246336 has been marked as a duplicate of this bug. ***
*** Bug 295437 has been marked as a duplicate of this bug. ***
*** Bug 297081 has been marked as a duplicate of this bug. ***
Is this related to this bug? After the first input the focus moves to input 3 but no cursor is shown.
*** Bug 298454 has been marked as a duplicate of this bug. ***
*** This bug has been marked as a duplicate of 167801 ***
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → DUPLICATE
Component: Layout: View Rendering → Layout: Web Painting
You need to log in before you can comment on or make changes to this bug.