clicking in text field doesn't display carat at first



18 years ago
14 years ago


(Reporter: jhp (no longer active), Assigned: aaronr)


Firefox Tracking Flags

(Not tracked)


(Whiteboard: CMVC32752)



18 years ago
If you go to 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

18 years ago
The square problem is this bug:

Comment 2

18 years ago
Assignee: mkaply → mozilla
Keywords: helpwanted
Whiteboard: CMVC32752

Comment 3

18 years ago
I'll try to fix this puppy.

Comment 4

18 years ago
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.

Comment 5

18 years ago
Assigning to myself
Assignee: mozilla → aaronr


18 years ago
Keywords: helpwanted

Comment 6

18 years ago
removed help wanted keyword

Comment 7

18 years ago
*** Bug 58449 has been marked as a duplicate of this bug. ***

Comment 8

18 years ago
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.

Comment 9

18 years ago
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.

Comment 10

18 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

18 years ago
*** Bug 59960 has been marked as a duplicate of this bug. ***

Comment 12

18 years ago
Fix checked in.
Last Resolved: 18 years ago
Resolution: --- → FIXED

Comment 13

18 years ago

Comment 14

17 years ago
Marking verified
Product: Browser → Seamonkey
You need to log in before you can comment on or make changes to this bug.