Closed Bug 190290 Opened 23 years ago Closed 20 years ago

[FIX] Caret mispositioned when the input is in a positioned div

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: helmut.ackermann, Assigned: MatsPalmgren_bugz)

References

Details

(Keywords: testcase)

Attachments

(3 files)

reporter's testcase
4.52 KB, text/html
Details
Simpler Testcase
635 bytes, text/html
Details
Patch rev. 1
2.89 KB, patch
bzbarsky
: review+
roc
: superreview+
Details | Diff | Splinter Review
User-Agent: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 Build Identifier: Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.1) Gecko/20020826 I have a simple html-file (see below) containing a form element that is positioned fixed with CCS style attributes. The form element itself contains a select element with four option values. The position of this select element ist absolute within a div-element that is positioned relative to the containing form element. Positioning the mouse over the correctly rendered selection element and click will not show the available options, the value remains fixed to the default value. There is second minor bug observed within the same form block. The input text element following the selection element accepts inputs, but the text cursor is in the wrong height, like as if the absolute position value would e top: 0; Here is my test html file: <html> <head> <META http-equiv="Content-Type" content="text/html; charset=UTF-8"> <meta content="text/html;charset=UTF-8" http-equiv="content-type"> <meta content="hackermann" name="generator"> <meta content="text/javascript" http-equiv="Content-Script-Type"> <title>Test CSS position fixed form block</title> <style> body { font-family: Verdana, Arial, Helvetica, sans-serif; font-size: 1.0em; } .qForm { position: fixed; top: 2em; left: auto; right: 1em; font-size: 0.8em; margin: 1em 1em 1em 1em; border-width: medium; border-style: solid; border-color: rgb(0,0,100); padding: 1.3em 1em 1.5em 1em; background-color: white; width: 16em; } /* bug with internet explorer */ //body>form.qForm { position: fixed } .qTitle { position: absolute; top: -0.8em; left: 2em; margin: 0em 0em 0em 0emx; padding: 0em 1em 0em 1em; background-color: white; font-weight: bold; font-size: 1.0em; } .qTerm { position: relative; height: 3.0em; width: auto; margin: 0.2em 0em 0.2em 0em; } .qLabel { width: 16em; text-align: left; font-size: 0.8em; } .qField { position: absolute; top: 1.0em; left: 0em; width: 16em; height: 1.6em; margin: 0em 0em 0em 0em; padding: 0em 0em 0.2em 0em; border-width: thin; border-color: rgb(0,0,100); border-style: solid; font-size: 1.0em; } .qButton { position: absolute; top: 0.6em; margin: 0.4em 0em 0.4em 0em; padding: 0.3em 0.3em 0.3em 0.3em; border-width: 2px; border-style: outset; width: 5em; height: 2.2em; background-color: rgb(240,240,255); color: black; font-weight: normal; font-size: 1.0em; } </style> </head> <body> <form class="qForm" method="post" action=""> <div class="qTitle">Fixed Form</div> <div class="qTerm"> <div class="qLabel">Version:</div> <select size="1" name="branch-input" id="branch-input" class="qField"> <option>8.0</option> <option>8.1</option> <option>8.1.1</option> <option>8.2</option> </select> </div> <div class="qTerm"> <div class="qLabel">Key:</div> <input class="qField" size="20" value="any" name="key-input" id="key-input" type="text" > </div> <div class="qTerm"> <input style="left: 1em;" value="reset" name="Reset" type="reset" class="qButton"> <input style="right: 1em;"value="submit" name="Search" type="submit" class="qButton"> </div> </form> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> <h1>bla bla</h1> <p>bla bla</p> </body> </html> Reproducible: Always Steps to Reproduce: 1. Load the html file above 2. Try to change the value of the version field 3. (Second error) try to eit the text input field 'key' Actual Results: Nothing Expected Results: Mozilla should present all the option of the selection field and should set the value as the user slect it.
This worksforme, linux trunk build 2003-01-21-08, with that testcase.... Is this a problem on Windows in a recent build? (1.1 is about 6 months old; a lot has changed since).
Now I viewed my Test Page again with a freshly installed Version Mozilla 1.2.1 ( Mozilla/5.0 (Windows; U; WinNT4.0; en-US; rv:1.2.1) Gecko/20021130 ) and with this newer Version the select element works fine. But the text cursor in the text-input element is still misplaced (a little to high at the text page).
Yeah, I see that too. A minimal testcase would be nice (I doubt half the CSS/HTML in there is needed to reproduce that problem).
Keywords: qawanted
Attached file Simpler Testcase —
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows NT → All
Hardware: PC → All
Summary: The relative-positioned 'select-input-elem' in a fixed positioned form block accepts no input → Cursor mispositioned when the input is in a positioned div
An observation. When you click within the textbox, even though the cursor does not appear in the textbox, you can edit the text. Double, triple clicks do select the appropriate text. Keyboard input does make the appropriate changes.
Keywords: qawanted → testcase
*** Bug 282927 has been marked as a duplicate of this bug. ***
Assignee: layout.form-controls → mats.palmgren
Summary: Cursor mispositioned when the input is in a positioned div → [FIX] Caret mispositioned when the input is in a positioned div
Attached patch Patch rev. 1 — — Splinter Review
This fixes the testcases. The "window-relative coordinates" block near the end probably also needs the same fix, but I don't know how to construct a testcase for that bit so I don't dare changing it..
Attachment #174946 - Flags: superreview?(bzbarsky)
Attachment #174946 - Flags: review?(bzbarsky)
Comment on attachment 174946 [details] [diff] [review] Patch rev. 1 >Index: layout/base/nsCaret.cpp >+ nsRect bounds = theView->GetBounds(); >+ drawViewOffset += theView->GetPosition() - nsPoint(bounds.x, bounds.y); Why not: drawViewOffset += theView->GetPosition() - theView->GetBounds().TopLeft() ? That said, I think all this code is pretty bogus... its cliprect calculation makes no sense to me, and I think it would be better to just use view->GetNearestWidget() (which will properly compute coords) and then get the view for that widget (Robert suggested having a public api for that). I guess it's ok to do this for now, but maybe file a bug on bringing sanity to this code? -Boris
Attachment #174946 - Flags: superreview?(roc)
Attachment #174946 - Flags: superreview?(bzbarsky)
Attachment #174946 - Flags: review?(bzbarsky)
Attachment #174946 - Flags: review+
The caret code is entirely bogus. It needs to be overhauled so that the caret always belongs to a frame (an nsTextFrame, probably) and is painted by that frame's Paint method. Currently caret painting doesn't participate in the view manager's paint orchestration so it doesn't obey clipping, z-ordering, and other requirements. (It also won't work when we start doing SVG transforms on HTML.)
Comment on attachment 174946 [details] [diff] [review] Patch rev. 1 what bz said about TopLeft()
Attachment #174946 - Flags: superreview?(roc) → superreview+
Filed bug 287813 on the nsCaret overhaul suggested in comment 9/10. Changed to using TopLeft() and checked in 2005-03-26 06:50 PDT. -> FIXED
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → FIXED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: