226933 - Caret vanishes in input form elements over iframe

Status: VERIFIED FIXED

(Core :: Web Painting, defect)

Description

[Christian Bricart]

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

Comment 1

[Christian Bricart]

Attachment: small testcase illustrating the bug

Comment 2

[Christian Bricart]

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

Comment 3

[u63580]

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

Comment 4

[Anne (:annevk)]

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

Comment 5

[Hermann Schwab]

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

[Emmanuel Bourg]

Confirming with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5)
Gecko/20031007

Comment 7

[Christian Bricart]

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

Sorry about the confusion

Comment 8

[u63580]

Ah, with you now.  The blinking caret does disappear, using the latest Win32
nightly (20031127)

Comment 9

[Boris Zbarsky [:bzbarsky]]

Dup of the "caret painting is all screwed up" bug... (that's not what its
summary is, unfortunately).

Comment 10

[Eugene Savitsky]

Dup of bug 208446?

Comment 11

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

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

Comment 12

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

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

Comment 13

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

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

Comment 14

[Roger Kovack]

Attachment: 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

[José Jeria]

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

Comment 16

[tgirmann]

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

[Darin Fisher]

Any hope of this bug being fixed for Gecko 1.8 ?

Comment 18

[Robert O'Callahan (:roc) (email my personal email if necessary)]

None. But mrbkap is working on a comprehensive fix for 1.9.

Comment 19

[kcoleman]

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. 

Comment 20

[Robert O'Callahan (:roc) (email my personal email if necessary)]

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.

Comment 21

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

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

Comment 22

[Reed Loden [:reed]]

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

Comment 23

[Martijn Wargers (dead)]

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

Comment 24

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

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.

Comment 25

[Mihai Bazon]

This bug still occurs in Firefox 2.0b2/Linux.

Comment 26

[Martijn Wargers (dead)]

(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

[Moacir Schmidt]

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

Comment 28

[Martijn Wargers (dead)]

Yes, Firefox2 is from the 1.8.1 branch. There is no plan to fix this for Firefox2, because that is considered too risky.

Comment 29

[Ria Klaassen (not reading all bugmail)]

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

Comment 30

[fknuefer]

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

Comment 31

[Peter van der Woude [:Peter6]]

(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

Comment 32

[Suomi Hasler, Ayni AG]

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

Comment 33

[Martijn Wargers (dead)]

In Firefox 3, because it is already fixed on trunk, which is where Firefox 3 will be made from.

Comment 34

[Johnny Stenback (:jst)]

Anyone know what fixed this and whether it would be feasible to port the fix to the branch?

Comment 35

[Blake Kaplan (:mrbkap) (inactive)]

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