Closed Bug 282358 Opened 15 years ago Closed 14 years ago

text caret disappears when using form fields inside a div with "position:fixed"

Categories

(Core :: Web Painting, defect)

x86
All
defect
Not set

Tracking

()

RESOLVED DUPLICATE of bug 230701

People

(Reporter: georg, Assigned: roc)

References

()

Details

(Keywords: testcase)

User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.8b) Gecko/20050214 Firefox/1.0+
Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; de-DE; rv:1.8b) Gecko/20050214 Firefox/1.0+

If you set up a page with a fixed div ( eg. background) and some divs for the
scrolling content inside of the fixed one. And now create a form inside the
content div, then the text caret disappears in tags input and textarea.

Here you can see a sample page:
http://www.lonux.de/demo

Reproducible: Always
Well, that sample page doesn't show anything for me.
This bug is probably a duplicate of bug 167801.
(In reply to comment #1)
> Well, that sample page doesn't show anything for me.
> This bug is probably a duplicate of bug 167801.
Please checkout the new example now at http://www.lonux.de/demo. Take attention
to the text caret inside the input field. In case the background div has
position:fixed the text caret disappears partially. You can scroll now to see
how the text caret behaves.
Furthermore there is a link on the top left corner for changing the position
attribute from the background div (fixed <-> absolute).
Well, that is also probably the same bug. I'll mark it dependent for now.
Assignee: firefox → roc
Component: General → Layout: View Rendering
Depends on: 167801
Product: Firefox → Core
QA Contact: general → ian
Version: unspecified → Trunk
This is the sort of thing that would be fixed by painting caret in frames.
This is an automated message, with ID "auto-resolve01".

This bug has had no comments for a long time. Statistically, we have found that
bug reports that have not been confirmed by a second user after three months are
highly unlikely to be the source of a fix to the code.

While your input is very important to us, our resources are limited and so we
are asking for your help in focussing our efforts. If you can still reproduce
this problem in the latest version of the product (see below for how to obtain a
copy) or, for feature requests, if it's not present in the latest version and
you still believe we should implement it, please visit the URL of this bug
(given at the top of this mail) and add a comment to that effect, giving more
reproduction information if you have it.

If it is not a problem any longer, you need take no action. If this bug is not
changed in any way in the next two weeks, it will be automatically resolved.
Thank you for your help in this matter.

The latest beta releases can be obtained from:
Firefox:     http://www.mozilla.org/projects/firefox/
Thunderbird: http://www.mozilla.org/products/thunderbird/releases/1.5beta1.html
Seamonkey:   http://www.mozilla.org/projects/seamonkey/
(In reply to comment #4)
> This is the sort of thing that would be fixed by painting caret in frames.

Hi,
great solution you are giving. 

The best solution would be not to use Firefox anymore ;)

This is definitely a bug because no other browsers (Opera, IE) behave in the
same manner. The text caret still disappears when the inputbox overlapps an
underlying layer which has position:fixed.
Tested with FireFox 1.0.7

Best regards,
Georg Lorenz
He meant that it will probably be fixed by the fix for bug 287813, which will
hopefully be included in the Firefox2.0 version.
Depends on: 287813
Status: UNCONFIRMED → NEW
Ever confirmed: true
(In reply to comment #7)
> He meant that it will probably be fixed by the fix for bug 287813, which will
> hopefully be included in the Firefox2.0 version.

Oh, sorry. And thanks for the review.
OS: Windows 2000 → All

*** This bug has been marked as a duplicate of 230701 ***
Status: NEW → RESOLVED
Closed: 14 years ago
No longer depends on: 167801, 287813
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.