56853 - clicking in text field doesn't display carat at first

Status: VERIFIED FIXED

(SeaMonkey :: General, defect, P3)

Description

[jhp (no longer active)]

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

[Mike Kaply [:mkaply]]

The square problem is this bug:

http://bugzilla.mozilla.org/show_bug.cgi?id=57006

Comment 2

[slaquinta]

SCREENED.  VERIFIED AS VALID.

Comment 3

[aaronr]

I'll try to fix this puppy.
--Aaron

Comment 4

[aaronr]

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

[aaronr]

Assigning to myself

Comment 6

[aaronr]

removed help wanted keyword

Comment 7

[Mike Kaply [:mkaply]]

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

Comment 8

[aaronr]

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

[aaronr]

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

[aaronr]

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

[Mike Kaply [:mkaply]]

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

Comment 12

[Mike Kaply [:mkaply]]

Fix checked in.

Comment 13

[Mike Kaply [:mkaply]]

Verified

Comment 14

[Mike Kaply [:mkaply]]

Marking verified