Closed Bug 75080 Opened 23 years ago Closed 23 years ago

caret position located in the wrong place until first character is entered

Categories

(Core :: Layout: Form Controls, defect)

Product:
Core
Component:
Layout: Form Controls
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
VERIFIED DUPLICATE of bug 55086
Milestone:
mozilla1.0

People

(Reporter: t.terlemez, Assigned: sfraser_bugs)

References

(
URL
)

Details

(Keywords: polish, regression, Whiteboard: [caret])

Attachments

(3 files)

Simplified test case: IMAGE plus TABLE with FORM inside.
259 bytes, text/html
Details
nytimes (books search form) web page reduced to a simple testcase.
170 bytes, text/html
Details
Test case with Image, File, and password
555 bytes, text/html
Details 
login form behaves abnormal (cursors starting at false places).
confirming with win2k / 20010406.. (CVS)
Status: UNCONFIRMED → NEW
Ever confirmed: true
occurs at build 2001040604 (I think started with mozilla 0.8.1)
confirmed for build 2001040608, PC, SuSE 7.0
Looks like a problem with font tags around form elements. See bug 75382 for a 
testcase.
*** Bug 75368 has been marked as a duplicate of this bug. ***
Summary: login form behaves abnormal (cursors starting at false places) → login form behaves abnormal (caret starting at false places)
This is a known issue and probably a dup
Summary: login form behaves abnormal (caret starting at false places) → [DUP?]login form behaves abnormal (caret starting at false places)
Target Milestone: --- → Future
Status: NEW → ASSIGNED
*** Bug 75732 has been marked as a duplicate of this bug. ***
*** Bug 76205 has been marked as a duplicate of this bug. ***
hello

I tested this bug again with build 2001041704 on Windows 2000 Prof. (at the
place I saw this bug : netaddress.usa.net and at the bug attach
http://bugzilla.mozilla.org/show_bug.cgi?id=75382 )

It is FIXED :)

thanks
Status: ASSIGNED → RESOLVED
Closed: 23 years ago
Resolution: --- → FIXED
verifying on build 2001-05-02-20-trunk
Status: RESOLVED → VERIFIED
A problem like this started again in Mozilla 0.9+ ( windows 2000 professional,
build 2001051804 and after 0.9)

at,
netaddress.usa.net
www.thecounter.com login forms you can see problem.

And now some last character of form fill area cannot be seen, like this :
if charater count bees odd different, even different ( at netaddress.usa.net
login form)

And, submit form not working when space bars pushed, but working with "enter".

final note : I couldnt login with mozilla build 2001051804 here, I am writing this bug note with Opera.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
I see the problem on thecounter.com but not on netaddress.usa.net. This is on 
build 2001-05-29-09-trunk windows 98
hello

there is a problem in form text areas now, do I write it as an another new bug ?

At www.netaddress.net (usa.net) in login area, while writing name and password,
if chacter count odd all characters can be seen but while count is even last one
or two characters is not visible.
I forgot to say, I used 2001053004 to test this case.
bug #79435 has some minimal testcases for the problem you are describing.
I'm not clear what the original problem reported here is.

*** Bug 82747 has been marked as a duplicate of this bug. ***
*** Bug 79994 has been marked as a duplicate of this bug. ***
*** Bug 82580 has been marked as a duplicate of this bug. ***
Changing summary since this is a more general bug

Adding keyword: polish
Keywords: polish
Summary: [DUP?]login form behaves abnormal (caret starting at false places) → Caret Starting at false position
Adding mostfreq keyword, setting OS to all. Why is this futured, it makes moz
look pretty bad ? Suggest making nscatfood.
Keywords: mostfreq
OS: Windows 2000 → All
Also, you can reproduce it very easily if you go to http://www.slashdot.org.

Scroll down the page a little, and then click in the 'login' box.

reassigning
Assignee: rods → beppe
Status: REOPENED → NEW
better summary; retarget and reassign to sfraser based on one of the duplicate 
bugs
Assignee: beppe → sfraser
Hardware: PC → All
Summary: Caret Starting at false position → caret position located in the wrong place until first character is entered
Target Milestone: Future → mozilla0.9.2
Whiteboard: [caret]
Target Milestone: mozilla0.9.2 → mozilla1.0
*** Bug 85072 has been marked as a duplicate of this bug. ***
Tested with N6 / M.6.. marking regression. 

Also there is this nice and simple real life example demonstrating the problem:
http://twig.screwdriver.net/demo/
Keywords: regression
NOte in the last example, the form have default values. All the default values
are originally placed in the wrong area. 

I will add another simple testcase. The next testcase is from the nytimes.com
evangelism bug: http://bugzilla.mozilla.org/show_bug.cgi?id=68262. That case we
do have the problem also in Netscape 6.01 / M.6 


*** Bug 85230 has been marked as a duplicate of this bug. ***
*** Bug 88934 has been marked as a duplicate of this bug. ***
Keywords: nsCatFood
This bug also affects the following form elements: Image, Password, File (in
addition to Text and Textarea). 

The form elements are displayed in the wrong place when they are in a table
below an image. They when they are displayed as if the images were not there.
Workaround is to place the image and form elements in the same table.
Changing the netsaddress.usa.net URL because they updated the page. Replacing with  
twig case which the problem is very visible...

Note that, in many of those cases, the caret position is in the right place
before the table/page layout start to change (due to image loading). Then when
images are loaded, the form field is updated to the proper position but the
caret cursor is not.
URL: http://netaddress.usa.net → http://twig.screwdriver.net/demo/
Here are possible workarounds: 
-----------------------------

1) we can wait for the images to be loaded then place the caret. 
or 
2) we can reflow the caret after the layout is stabilized (images loaded).

In many cases, if you have a very slow connection, you will see that originally
the caret was in the proper place. Disabling images, the following testcases 

PASS in the caret problem: 
------------------------------------------------------------------
http://twig.screwdriver.net/demo/
http://www.slashdot.org/
http://www.dhtmlplanet.com/
http://cvs.gnome.org/lxr/



*** Bug 91425 has been marked as a duplicate of this bug. ***
*** Bug 91918 has been marked as a duplicate of this bug. ***
*** Bug 92504 has been marked as a duplicate of this bug. ***
*** Bug 92796 has been marked as a duplicate of this bug. ***
this bug may be related to bug 82946
*** Bug 92932 has been marked as a duplicate of this bug. ***
This looks identical to bug 55086
duplicate

*** This bug has been marked as a duplicate of 55086 ***
Status: NEW → RESOLVED
Closed: 23 years ago → 23 years ago
Resolution: --- → DUPLICATE
Blocks: advocacybugs
No longer blocks: advocacybugs
verifying
Status: RESOLVED → VERIFIED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: