92464 - WRMB: Caret appears outside of text field

Status: VERIFIED DUPLICATE of bug 55086

(Core :: DOM: Editor, defect, P1)

Description

[Ari]

When single-line text fields receive focus, the caret sometimes appears
partially or completely outside of the text frame (sometimes way outside). In
other words, the text field and the caret are not in the same place. But, as
soon as any text is entered, the caret and the frame snap into their correct
positions (sometimes altering the layout of the page). Sometimes a misplaced
text frame can be covered by other form elements until the user enters text.
Once the user enters text, the layout changes so that the field is no longer
covered.

A minor example is the search field at the top of the PA site next to the "Pa
PowerSearch" image

Comment 1

[Ari]

Attachment: An example where the text field is covered by a form element

Comment 2

[Chad Austin]

What build are you using?  Do you have reproducable steps for this?

Comment 3

[Ari]

Attachment: A (minimal?) test case

Comment 4

[Ari]

I know it happens with Mozilla 0.9.2. I do not know exactly what steps it takes
to reproduce this problem. All I know is that in my test case, the form must be
enclosed in two tables, the outer of the two tables must be aligned center or
right, and the tag "<non-standard tag>" (it can be named anything) must be
present in order for the bug to be visible. Since this specific setup is not
present on the PA page, my test case does not encompass all possible causes.

Comment 5

[Mike Pinkerton (not reading bugmail)]

--> editor

Comment 6

[John Morrison]

I can see the caret outside the textfield, on win2k with the current .9.2.1
branch build. Confirming.

(I've also seen this happen when content is inserted by JS, forcing a table
further down the page, but leaving the logical location of textfields in 
that table at their original location).

Comment 7

[Ari]

Confirmed it on Mac OS X.

Comment 8

[rubydoo123]

off to mike

Comment 9

[Dave Barrowman]

Some real world examples:

http://twig.screwdriver.net/demo/
http://cvs.gnome.org/lxr/
http://www.slashdot.org/

Comment 10

[rubydoo123]

reassigning to karnaze -- this is a table reflow problem

Comment 11

[kinmoz]

FYI, if you try to pull some of these test cases locally, along with any images
on the page, you'll notice that you might not see the problem.

Apparently loading of images over the net introduces enough of a lag (timing
difference) that allows the reflow problems.

Comment 12

[karnaze (gone)]

Rod, please take a look. It could be a view and/or block problem, but it doesn't 
sound like a table problem.

Comment 13

[rods (gone)]

Works for me ok with today's build.

Comment 14

[Ari]

The bug is no longer evident in my test case attachments and in state.pa.us with
the 8/16/01 Win32 trunk build. But it remains in:

http://twig.screwdriver.net/demo/
http://cvs.gnome.org/lxr/

reopening...

Comment 15

[Christine Hoffman]

Tested on the following:

Comment 16

[Christine Hoffman]

Again....

Comment 17

[Christine Hoffman]

Tested on the following:

1) Built a debug build (8/16). Tested 'twig' page with Viewer - no problem. 
Tested 'twig' page with 'mfcembed' - I can reproduce the problem; however, when 
I resize the page, the problem corrects itself.

2) Downloaded the 8_16_10_trunk Netscape6.1 build. Tested 'twig' page in the 
browser - I can reproduce the problem.

Agree with reopen.

Comment 18

[rubydoo123]

using commercial build from 2001081703 (from sweetlou) this problem still 
exists. As Kin noted it is an issues with timing and reflow. The twig link is an 
excellent example.

I am setting this to 9.4, setting this to P1/Critical. This has been marked as 
WRMB.

Comment 19

[Ari]

Another example that has the bug under 0.9.3:

http://www.microsoft.com/windows/ie/

(the left side bar search field)

Comment 20

[rods (gone)]

erci, apparently this is a box layout issue, talk to kin if you need more info.

Thanks,
Rod

Comment 21

[Eric Vaughan]

taking a look.

Comment 22

[Eric Vaughan]

I believe this is a table bug. If the text field is in a table this happens. If
it is outside it does not. Attached are 2 testcases. The first shows the
problem. Shift-reload and you can see it everytime. The second one fixes the
problem by placing the textfield outside the table.

Comment 23

[Eric Vaughan]

Attachment: works fine because textfield is outside table

Comment 24

[Eric Vaughan]

Attachment: If you shift-reload this one always fails

Comment 25

[Ari]

Although I am not familiar with the code, it seems to me that if this were only
a table bug, the whole text field might be in wrong place, but not just the
contents and the caret. I would think that the text field would encapsulate all
of its visible components (such as the frame and the editor) and position them
relative to itself so that none of them could move without it. In other words, I
think that if the text fieled itself were working properly, it should be
impossible for the frame and the content to be in different places no matter
what is going on with the rest of the layout.

(Please correct me if I don't know what I'm taliking about.)

Comment 26

[rubydoo123]

adding karnaze

Comment 27

[Eric Vaughan]

>I would think that the text field would encapsulate all
>of its visible components (such as the frame and the editor) and position them
> relative to itself so that none of them could move without it.

Unfortunately this is not true. If we only had frames this might be the case but
we also have views. You can move the frames but if your children have a view and
the parent view is somewhere out side the textfield (Which it is). Then moving
only the frames and not the view will make this happen. Which I believe to be
the problem. But tracking down exacly where its happening is the really
difficult problem because this is due to content incrementally comming in. You
see the at first comes the image comes in with a size of 0,0. And a reflow
causes the textfield to be places properly. Then the images size pops in later.
The textfields frames are repositioned but their views are not moved. You can
also see this behavior without a text field. Put a div with overflow scroll in
the table cell and try it. The scrollbars will be in the wrong place.

Comment 28

[Eric Vaughan]

Attachment: The problem even happens without a textfield. Try clicking on the scroll arrow and you will see another nasty problem.

Comment 29

[Eric Vaughan]

Sorry guys. Its a table bug. The following attachment reproduces it with out
scrollbars or a text field. Load the following attachment and hit shift-reload.

Comment 30

[Eric Vaughan]

Attachment: Here it is try shift-reload.

Comment 31

[Eric Vaughan]

table bug

Comment 32

[Boris Zbarsky [:bzbarsky]]

*** This bug has been marked as a duplicate of 55086 ***

Comment 33

[sujay]

v