Caret vanishes in input form elements over iframe

VERIFIED FIXED

Status

()

Core
Layout: View Rendering
VERIFIED FIXED
15 years ago
4 years ago

People

(Reporter: Christian Bricart, Assigned: roc)

Tracking

(Blocks: 1 bug, {testcase})

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

Firefox Tracking Flags

(Not tracked)

Details

(Whiteboard: DUPEME)

Attachments

(2 attachments)

(Reporter)

Description

15 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.4) Gecko/20030630

when positioning a form over an iframe using position:absolute div, the typing
cursor vanishes while over the iframe

Reproducible: Always

Steps to Reproduce:
see attached testcase
(Reporter)

Comment 1

15 years ago
Created attachment 136409 [details]
small testcase illustrating the bug
(Reporter)

Comment 2

15 years ago
although, I filed this bug using rv:1.4 it's still valid on more recent versions
(including 1.5.1 and Mozilla-Firebird)

Updated

15 years ago
Keywords: testcase

Comment 3

15 years ago
WFM, Win2k, 20031114.  Reporter, when you say the cursor vanishes, I assume you
mean the pointer and not the I-bar?

Comment 4

15 years ago
He probably means the bar (I am almost certain of that).

Comment 5

15 years ago
re comment 3:
I assume by 'pointer' you are referring to the mouse cursor, and by I-bar you
are referring to the text cursor inside the text area.

When I´m clicking into the text area, a I-bar appears, like this one right
behind the last character I´ve just typed here.

Then I type 1234, and after typing each of these digits, there is a blinking
vertical line (I-bar?) at the right of the character just typed.
The one after the 4 seems to be in line with the left vertical border of the iframe.
Typing on, 56789012345678 I don´t see any blinking marker where to type next.
These characters are all inside the area also used by the iframe.
Typing next letter 9, which crosses the right border of the underlying iframe,
the textcursor reappears, outside the area used by the iframe.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.4.1) Gecko/20031008
and also seen on current nightly.

Comment 6

15 years ago
Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5)
Gecko/20031007
Status: UNCONFIRMED → NEW
Ever confirmed: true
(Reporter)

Comment 7

15 years ago
I think "(blinking) caret" would be the appropriate term for "cursor" here.
Comment #5 describes what I meant.

Sorry about the confusion

Comment 8

15 years ago
Ah, with you now.  The blinking caret does disappear, using the latest Win32
nightly (20031127)
Dup of the "caret painting is all screwed up" bug... (that's not what its
summary is, unfortunately).
Whiteboard: DUPEME

Comment 10

14 years ago
Dup of bug 208446?
*** Bug 263900 has been marked as a duplicate of this bug. ***
*** Bug 279455 has been marked as a duplicate of this bug. ***
*** Bug 267206 has been marked as a duplicate of this bug. ***

Updated

14 years ago
Blocks: 226301

Comment 14

14 years ago
Created attachment 177315 [details]
insertion cursor disappears over scrolling DIV

Test case for this disappearing cursor problem over an underlying scrolling
DIV, not an IFRAME. Does not occur if the DIV is not scrolling.
See http://sonic.net/~pagan/editoverscroller.html 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.5) Gecko/20041107
Firefox/1.0
Win2K SP4

Comment 15

13 years ago
*** Bug 291093 has been marked as a duplicate of this bug. ***

Comment 16

13 years ago
The insertion cursor even disappears if the scrolling div is given a style
"visibility:hidden;", e.g. by using the DOM inspector on the test case.

Comment 17

13 years ago
Any hope of this bug being fixed for Gecko 1.8 ?
None. But mrbkap is working on a comprehensive fix for 1.9.

Comment 19

13 years ago
I'm working on a new product that will have a lot of usage. We're currently
running into this bug and are hoping it can be fixed in the Firefox 1.1 release. 
Flags: blocking-aviary1.1+

Updated

13 years ago
Flags: blocking-aviary1.1+ → blocking-aviary1.1?
See comment #17.

You may be able to work around the bug by wrapping an INPUT in a DIV that has
"overflow:auto; position:relative" and setting z-index on the DIV too.

Updated

13 years ago
Depends on: 167801

Updated

13 years ago
Flags: blocking-aviary1.1? → blocking1.8b4?

Updated

13 years ago
Flags: blocking1.8b4? → blocking1.8b4-

Updated

13 years ago
Summary: cursor vanishes in input form elements over iframe → Caret vanishes in input form elements over iframe
Depends on: 287813
No longer blocks: 230701
*** Bug 323053 has been marked as a duplicate of this bug. ***
Is this bug's fix still going for Gecko 1.9 or is there any way it could make Gecko 1.8 (Firefox 2 or so)?
No problem anymore with 2006-04-18 trunk build on windows. Testcase is worksforme now. Fixed by bug 287813.
Status: NEW → RESOLVED
Last Resolved: 12 years ago
Resolution: --- → FIXED
Verified FIXED using build 2006-04-28-05 of SeaMonkey trunk in Windows XP with the testcases:

https://bugzilla.mozilla.org/attachment.cgi?id=177315
--and--
https://bugzilla.mozilla.org/attachment.cgi?id=136409

I saw no problem with either, now.
Status: RESOLVED → VERIFIED

Comment 25

12 years ago
This bug still occurs in Firefox 2.0b2/Linux.
(In reply to comment #25)
> This bug still occurs in Firefox 2.0b2/Linux.

That's because the patch that fixed this bug (the patch from bug 287813) didn't go into the 1.8.1 branch, because it was considered much too risky and depended on all kinds of trunk changes.

Comment 27

12 years ago
(In reply to comment #26)
> (In reply to comment #25)
> > This bug still occurs in Firefox 2.0b2/Linux.
> 
> That's because the patch that fixed this bug (the patch from bug 287813) didn't
> go into the 1.8.1 branch, because it was considered much too risky and depended
> on all kinds of trunk changes.
> 
Well...The bug in testecase:

https://bugzilla.mozilla.org/attachment.cgi?id=177315

still occurs in Firefox 2.0 RC2...2.0 is from the branch 1.8.1? if yes, is there a plan to include this bug correction in a official future branch?
Yes, Firefox2 is from the 1.8.1 branch. There is no plan to fix this for Firefox2, because that is considered too risky.
*** Bug 358198 has been marked as a duplicate of this bug. ***

Comment 30

12 years ago
Can't believe that this is still not fixed in 2.0. This has a considerabl impact on site we are developing. Is there a schedule for including this fix? Seriously, this thing has been hanging around for 3 years now!!
(In reply to comment #30)
> Can't believe that this is still not fixed in 2.0. This has a considerabl
> impact on site we are developing. Is there a schedule for including this fix?
> Seriously, this thing has been hanging around for 3 years now!!
> 
read comment #28
(In reply to comment #28)
> Yes, Firefox2 is from the 1.8.1 branch. There is no plan to fix this for
> Firefox2, because that is considered too risky.
> 
just downloaded ff 2.0.2 and, disapointingly, the bug is still there. so when do you consider to correct it really? 
In Firefox 3, because it is already fixed on trunk, which is where Firefox 3 will be made from.
Anyone know what fixed this and whether it would be feasible to port the fix to the branch?
(In reply to comment #34)
> Anyone know what fixed this and whether it would be feasible to port the fix to
> the branch?

See comment 26, bug 287813 (the caret overhaul) fixed this and other caret-over-odd-stuff bugs.
You need to log in before you can comment on or make changes to this bug.