58712 - TAB key at beginning of blank line in TEXTAREA behaves strangely

Status: RESOLVED FIXED

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

Description

[Scott Gifford (old account)]

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; Linux 2.2.14-5.0 i686; en-US; m18) Gecko/20001014
BuildID:    0000000000 (CVS 10/31/2000)

If I go to the beginning of a blank line in a TEXTAREA of an HTML form and hit
TAB, the cursor moves over one space; when I begin typing, it jumps to the
correct position before displaying text.

Reproducible: Always
Steps to Reproduce:
1.Visit an HTML form with a TEXTAREA.

2.Move the cursor to the beginning of a blank line (ie, click in the empty
textarea, or hit ENTER after entering some text)

3.Hit TAB

Actual Results:  The cursor moves over a single space.

Expected Results:  The cursor moving over about 8 spaces.

As soon as I type a character, the tab repositions itself correctly.

Comment 1

[Fabian Guisset]

Confirmed on build 2000103104 win32. The first tab moves the cursor by one 
space, and pressing a key starts writing about 8 chars further. However only the 
first tab does this. If you press tab two or more times, it works as it should.
Fabian.

Comment 2

[Scott Gifford (old account)]

On my build, if you press tab two or more times, the second and further tabs
each move over 8 characters, but the first tab remains a single space until you
type something other than a tab.

Comment 3

[Kathleen :Brade]

confirming bug; I see this on Macintosh as well (2000103114).
This is probably Joe's bug?

Comment 4

[rods (gone)]

reassigning

Comment 5

[Joe Francis]

probably me: might be layout, but i'll triage

Comment 6

[Kathleen :Brade]

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

Comment 7

[Bradley Baetz]

This happens for me if the tab is the last character on the line - it doesn't
have to be at the beginning of the line. Current CVS build.

Comment 8

[Scott Gifford (old account)]

Just an update, I'm still seeing this bug in build 2000120608.

Comment 9

[rubydoo123]

assigning to moz0.9.1

Comment 10

[Tony Garnock-Jones]

Just a thought - could bug 67907 (TAB key no longer working in TEXTAREAs) be
related to this?

Comment 11

[Kathleen :Brade]

I don't think so since that bug claims that it was working in the 2001-01-28-06 
build but was broken in the 2001-01-28-21 build and this bug was filed long 
before that.

This bug may not matter; depends on the outcome of the spec in bug #66285.  I'll 
add the dependency.

Comment 12

[Vladimir Ermakov]

QA Contact Update

Comment 13

[Scott Gifford (old account)]

I'm now seeing TAB in a <TEXTAREA> taking me to the next control.  Is that now
the correct behavior?...I see a lot of discussion about this topic, but no
resolution.  If moving to the next control *is* the correct behavior, this bug
can be closed.

But I hope that's not the case...

Comment 14

[Joe Francis]

this is a layout prob, though it may be hidden now by the tab focus shifting.  
bouncing back to rod

Comment 15

[rods (gone)]

reassigning

Comment 16

[Joe Francis]

turns out this was intentionally done by [e-mail].  See bug 47282.  
cc'ing interested parties.  Futuring until it's decided what we want here.

Comment 17

[Jason Goodman]

This bug also occurs in the Mail Compose window, where it's unbelievably annoying.

There seems to be some disagreement in bug 47282 (and bug 29086) over whether
"tab" should go to the next widget or insert a tab in a browser form.  But in
the body textarea of Mail Compose, there's little ambiguity: it's unlikely
you'll want to move out of the body textarea once you've entered it, and one
very often needs to put tabs in the message.

Jfrancis says that this bug may be made moot by making tab go to the next widget
in the browser.  But some people are arguing in 47282 and 29086 that tab
behavior in mail compose windows should be a special case, and insert tabs.  If
that happens (and I think it should), this bug (58712) will not be made moot.  

I think everyone would agree that the single-space tab behavior described here
is wrong.  I think it should be fixed, so that it doesn't crop up again after a
decision is made on bug 29086.

Comment 18

[Kathleen :Brade]

-->jfrancis

Comment 19

[Joe Francis]

The tab is in the content model.  Don't know why caret is not drawing in correct 
place.  It's either layout or selection or caret prob.  Bouncing to selection.

Note: you need to test in plaintext mail compose to see this.

Comment 20

[Kathleen :Brade]

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

Comment 21

[Shotaro Kamio]

reproduced in text mail editor of Mozilla 2001110121/Linux.
In text mail editor,
Type TAB, the cursor moves one space.
Type any key after that, the cursor moves correctly.
If type TAB many times, the last TAB is wrong.

I found the strange point in source code.
here is the point.
http://lxr.mozilla.org/seamonkey/source/layout/html/base/src/nsTextFrame.cpp#3655

3655 PRInt32* ip = indexBuffer.mBuffer;
3656 if (inOffset > mContentLength){
3657 NS_ASSERTION(0, "invalid offset passed to GetPointFromOffset");
3658 inOffset = mContentLength;
3659 }
3660 3661 while (inOffset >=0 && ip[inOffset] < mContentOffset) //buffer has shrunk
3662 inOffset --;

Probably, pointer "ip" represent an array of the columns of characters.
( I don't know much about Mozilla source code. So, this is Probably).
I insert codes for dump ip[]. results is below.

Type TAB in beginning of mail body,
  ip[0]=0,ip[1]=1
this indicate the first char is one space.
Type TAB once again,
  ip[0]=0,ip[1]=8,ip[2]=9
this indicate the first TAB is ok, but second TAB is one space.

I can't understand more detail of source code.
Please, Please, fix this bug!

Comment 22

[Shotaro Kamio]

Attachment: one line change

Comment 23

[Shotaro Kamio]

Oops, patch went above of this comment.

I did It !
I changed one line on source code. Then, this bug went away.

Please test and check this code everyone.

Comment 24

[Joe Francis]

kin, mike, dbaron... could one of you take a look at the patch?

Comment 25

[Shotaro Kamio]

I confirmed on 2002030607/Linux.
I hope this bug will be fixed by 1.0.

I'll post new patch.

Comment 26

[Shotaro Kamio]

Attachment: a new patch

Comment 27

[Andrew Lin]

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

Comment 28

[Kathleen :Brade]

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

Comment 29

[Tuukka Tolvanen (sp3000)]

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

Comment 30

[Sean Jensen-Grey]

This bug still exsits.

I am using

Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:0.9.9+) Gecko/20020419

I didn't patch as I am running a nightly from a couple days ago.

Comment 31

[kinmoz]

The ip[] array that PrepareUnicodeText() builds up is basically a mapping from 
an index in the source content (text node fragment) to an index in the 
aTextBuffer content (text buffer used to paint and calculate the next visible 
char for selection). Note that the indexes in aTextBuffer are offset by 
mContentOffset.

The length of aTextBuffer can differ from the source content because of white 
space compression, tab character expansion, etc.

In the loop that processes the fragment's contents, strInx is incremented to 
account for the spaces used to render the tab. If there is a character after the 
tab, the ip[] entry for the char will get strInx. If there is no char after the 
tab, we fall out of the loop and hit the selection code which merely increments 
the last ip[] entry to point at the 2nd space used for the tab which is wrong.

Note that when we are outside the loop, we can't simply rely on strInx to give 
us the position after the last char because of the fact that it could be thrown 
out of sync by the code that deletes trailing whitespace.

That all said, I think that Shotaro's fix might be correct.

I'm willing to sr=kin if mjudge or someone familiar with this part of layout can 
r=.

Comment 32

[mjudge]

yes this looks good. probably never thought of this when I coded it.  This 
looks good to me. can i review my own bug if i did not invent the patch?

Comment 33

[saari (gone)]

Yes, it still counts as a review if you didn't do the patch.

Comment 34

[Stephan Golux]

This bug still frustrating in the mail edit window in RC2 (2002051006).  Any
chance this gets fixed for the real 1.0?

Comment 35

[guanxi]

Could someone look at Bug 143763, Problem #2 and see if it's caused by the same
bug?  If it is, I'll move the details of Problem #2 to a comment over here and
consolidate the bugs.

Problem 1 dupes this bug (thanks to Andrew for finding the dupe).  I'm not sure
if Problem 2 is somehow related.

Stephan -- you might be interested in the details of 143763.  I agree that it's
important to fix;  tabs are very basic functionality in e-mail messages.

Comment 36

[Shotaro Kamio]

I think that Problem 2) of Bug 143763 is different from this bug.
Because my patch can't fix it.
I'll give some additional comments in Bug 143763.

Comment 37

[Jesse Ruderman]

WFM in composer and message compose (2002 050908 on Windows 98).

Comment 38

[Jim Garrison]

Still broken in RC2 {2002051006} on Windows 2000 and Linux.

Comment 39

[Jim Garrison]

Still broken in RC3 {2002-0523-06} on Windows 2000 and Linux.
This is incredibly annoying in mail compose.  IMHO this *REALLY*
should be fixed before 1.0, at least for mail compose.

Comment 40

[Stephan Golux]

Still broken in RC3 on Win 98 as well.  This looks really bad.  I feel that if
this isn't in 1.0, Mozilla will be just laughed out of the browser wars.  Mail
compose is constantly a frustrating nightmare.

Comment 41

[Brendan Eich [:brendan]]

Too late for 1.0, fix it in 1.0.1 -- there's life after 1.0, the war goes on. :-/

Can we get this bug targeted out of Future, please?

/be

Comment 42

[kinmoz]

I stepped through the algorithm a while back, and it looked like it was the
right thing to do ... since that method skamio is modifying is critical to
painting and selection, I'd like another person familiar with the code to do the
same exercise I did to make sure it won't introduce any unwanted side effects
... smontagu, your group owns this code right? Care to review it?

Comment 43

[kinmoz]

Hmmmm, just noticed mjudge's comment in comment 32.

mjudge, does that mean you're giving an r=mjudge?

Comment 44

[Simon Montagu :smontagu]

shanjian, I think you know this code better than I do. are you willing to r= the
patch?

Comment 45

[Shotaro Kamio]

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

Comment 46

[Shanjian Li]

Comment on attachment 72915 [details] [diff] [review]
a new patch

It makes sense to me. The patch explained why the last TAB (in boundary) causes
the problem. r=shanjian

Comment 47

[kinmoz]

Comment on attachment 72915 [details] [diff] [review]
a new patch

sr=[e-mail]

Comment 48

[mjudge]

yeah i would have given it a review but i didnt know if i could r= my own bug. I 
will check this in.

Comment 49

[Shotaro Kamio]

mjudge checked-in my patch into trunk.
I confirmed on 2002061808/Linux.

Comment 50

[Shotaro Kamio]

How about check-in to 1.0branch?

Comment 51

[Judson Valeski]

minusing for 1.0.1. we're going on the door w/ lots of annoyances, this will
have to be another.

Comment 52

[Dawn Endico]

Removing the item for this bug from the release notes for 1.1beta and beyond.