Closed
Bug 56853
Opened 24 years ago
Closed 24 years ago
clicking in text field doesn't display carat at first
Categories
(SeaMonkey :: General, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
People
(Reporter: jhpedemonte, Assigned: aaronr)
References
Details
(Whiteboard: CMVC32752)
If you go to lxr.mozilla.org/seamonkey and click in one of the text fields, the carat does not display until you start typing. It is almost as if it is too far left. Another good example is the "Enter New Bug" page on Bugzilla. Clicking in the "Summary" field does not display the carat until you type in a letter. However, if you go down to the text box at "Description", the carat is displayed. Also, the carat is different between the two ("URL" is an <INPUT> tag, while "Description" is a <TEXTAREA> tag). The TEXTAREA carat looks more like an outline of the carat.
Comment 1•24 years ago
|
||
The square problem is this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=57006
SCREENED. VERIFIED AS VALID.
We need to move the cursor over a pel or reduce the width of the shadowing on text controls a pel. Probably need to move the cursor as it doesn't seem that the text control knows how thick the shadowing is. If you type a '8' in a textfield, you'll notice that the left most edge of the 8 actually appears to be in the shadow.
Keywords: helpwanted
Looks like the os/2 build has a 3 pixel border, but only 2 for windows. The cursor is being drawn along the 3rd pixel (most inside edge) so that is why we aren't seeing it. I am trying to figure out why we are at 3 pixels but only 2 for Windows. Buttons and comboboxes also have too thick a 3d effect.
This isn't a hardcoded factor like 57006 mentioned below. We are getting the proper twipsPerPixel (12 for os/2, 15 for windows). I noticed that when I changed the border width in quirk.css, that if I set it to 1px, then the border correctly became 1px. But if I made it any value x>1, then the number of pixels on the border became x+1. If I made it 15px, then there would be 16 pixels making up the border. Windows does not have this problem. It changes to reflect the correct number of pixels. Hmmmm.
Assignee | ||
Comment 10•24 years ago
|
||
The problem turns out to be that we specify POLYGON_INCL and POLYGON_BOUNDARY in our call to GpiPolygons inside nsRenderingContextOS2::PMDrawPoly. By removing these the problem goes away. I didn't see where Windows calls have any concept of BOUNDARY in their ::Polygon function and Idon't see where they worry about including the corner or not. So I think that we'll be safe with this fix.
Comment 11•24 years ago
|
||
*** Bug 59960 has been marked as a duplicate of this bug. ***
Comment 12•24 years ago
|
||
Fix checked in.
Status: NEW → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
Comment 13•24 years ago
|
||
Verified
Updated•20 years ago
|
Product: Browser → Seamonkey
You need to log in
before you can comment on or make changes to this bug.
Description
•