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.
The square problem is this bug: http://bugzilla.mozilla.org/show_bug.cgi?id=57006
SCREENED. VERIFIED AS VALID.
Assignee: mkaply → mozilla
I'll try to fix this puppy. --Aaron
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.
Assigning to myself
Assignee: mozilla → aaronr
removed help wanted keyword
*** Bug 58449 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 59960 has been marked as a duplicate of this bug. ***
Fix checked in.
Status: NEW → RESOLVED
Last Resolved: 18 years ago
Resolution: --- → FIXED
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.