88690 - every other character shows up when typing

Status: VERIFIED FIXED

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

Description

[Dan Naumov]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:0.9.2) Gecko/20010628
BuildID:    2001062815

You'll encounter lots of trouble with making posts in this forum if you're using
Mozilla. See "Steps to Reproduce".

Reproducible: Always
Steps to Reproduce:
1. Go to http://forums.foop.fi/demi/
2. On the left table, there's a login form, login as mozilla/mozilla.
3. Click on any thread.
4. Go to the bottom of the page and click on the "Viestisi:" form.
5. Type a few lines of text, make sure your cursor is at the end of the message
and try to delete the last symbol with Backspace.

Actual Results:  The last symbol gets deleted (as it should've happened), but
the cursor gets moved to the beginning of the message. After this, you'll also
have trouble moving around the form using the Left and Right arrows on your
keyboard.

Expected Results:  The last symbol should've gotten deleted without any of the
bugs appearing.

Maybe a Javascript problem ?

Comment 1

[Dan Naumov]

I've also noticed that after completing the step 5 (after you cursor gets moved
to the beginning of the message), you can't move around the message by using the
Home/End buttons as well.

However, if you click somewhere on the text with the left mouse button, you can
move around again (ie. Home/End/arrows work after that).

Comment 2

[Francisco León]

Weird behaviour all together on that form. No javascript problems in the console
Evangelism? I dont know
Marking NEW

Comment 3

[Markus Gerstel]

I'm on it. Seems like a <table>-issue

Comment 4

[Markus Gerstel]

Got it. Smallest code to reproduce this bug is :

<table width=486 border=1><tr><td>
<font>
:
<textarea cols=40 style="font-family:serif;"></textarea>
</td></tr></table>
Problem only occurs if the <font>-Tag AND the ':' (or any other text) are
present. Furthermore the <table> must limit the textarea's width (border is not
necessary).

The effect occurs only if the textarea's font is a non-monospace (not: courier,
etc) one ?
Good luck with this one =)

Comment 5

[Markus Gerstel]

Attachment: Example code once again

Comment 6

[Francisco León]

So, should i put this one as HTMLTables or form controls?

Comment 7

[Markus Gerstel]

I suggest Form Controls. The table is OK, the textarea is the problem.

Comment 8

[Francisco León]

So be it
->Form Controls

Comment 9

[timeless]

.

Comment 10

[Asa Dotzler [:asa]]

->editor

Comment 11

[rubydoo123]

mjudge has an open bug on navigation, assigning to mike.

Comment 12

[sujay]

Dan Naumov, please download latest build and try again.
bug 88164 got fixed, so that should fix this problem.

Then close this bug out if it is fixed for you...

thanks.

Comment 13

[mjudge]

what the heck is going on? the caret in a sense is in the correct place. i mean 
i can backspace and backspace again and it seem sok. but the caret is flying to 
the beginning of the line visually.... the heck is this?

Comment 14

[mjudge]

umm as i enter text into this form. every other character doesnt APPEAR to enter 
until the next one is pressed.  aka
*hit a
see nothing
*hit b
see ab
*hit c
see ab
*hit d
see abcd
ect...

This is some kind of refresh problem here. not sure who needs to see this. i 
think i may be over my head with this refresh stuff

Comment 15

[rubydoo123]

adding attinasi to cc list and kin, maybe they have some insight to what the
problem is

Comment 16

[Dan Naumov]

I am still having problems with this form, using a newer build now: 2001070808.
I am still getting the same weird behaviour.

Comment 17

[mjudge]

i want to just give this to a layout person now. I will never be able to fix 
this one myself. who can i give it to?

Comment 18

[mjudge]

i am going to assign this to waterson because i hate him.

Comment 19

[Chris Waterson]

That's right. FEEEEEEL your hate!

Comment 20

[Chris Waterson]

What mjudge describes sounds like bug 91423, which has a much better test case.
Is this a dup of that bug?

Comment 21

[kinmoz]

Looks like it may be related to bug 91423. FYI, I couldn't reproduce the 
original reported problem (cursor flying to start of line) with my debug Win32 
build, until, I saved the file locally and forced the textarea to wrap below the 
word "Viestisi:" (just like  91423).

After that, I could type some word in the empty textarea, and see every other 
character appear, and also see that each hit of backspace makes the caret fly to 
the beginning of the line while deleting the correct character ... which 
indicates that the caret/selection is in the correct place.

Comment 22

[Chris Waterson]

Marking dependency -- hopefully a dup.

Comment 23

[Chris Waterson]

Re-summarizing. Note that the problem now appears in the _login_ window with a
trunk build (post checkin for bug 91423): sounds like bug 116230.

Comment 24

[Boris Zbarsky [:bzbarsky]]

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

Comment 25

[Randell Jesup [:jesup] (needinfo me)]

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

Comment 26

[Randell Jesup [:jesup] (needinfo me)]

Just duped a bug against this that had a "blocker" severity, so severity
updated.  This is happening a lot, and making text input very painful.  My
testcase was trying to forward a news.com story to someone using the "email to a
friend" or whatever link.  Perhaps this bug got worse recently?

Comment 27

[Chris Waterson]

There's a fix in bug 116230, awaiting super-review. (Hint, hint.)

Comment 28

[Chris Waterson]

This should be fixed now that 91423 and 116230 are.

Comment 29

[sujay]

Dan, please verify and mark verified fixed....thanks..

Comment 30

[sairuh (rarely reading bugmail)]

not a problem with current trunk builds.