Closed Bug 58712 Opened 21 years ago Closed 19 years ago

TAB key at beginning of blank line in TEXTAREA behaves strangely

Categories

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

defect

Tracking

()

RESOLVED FIXED
Future

People

(Reporter: sgifford+mozilla-old, Assigned: mjudge)

References

Details

Attachments

(1 file, 1 obsolete file)

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.
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.
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.
confirming bug; I see this on Macintosh as well (2000103114).
This is probably Joe's bug?
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Linux → All
Hardware: PC → All
reassigning
Assignee: rods → beppe
probably me: might be layout, but i'll triage
Assignee: beppe → jfrancis
*** Bug 59541 has been marked as a duplicate of this bug. ***
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.
Just an update, I'm still seeing this bug in build 2000120608.
assigning to moz0.9.1
Target Milestone: --- → mozilla0.9.1
Just a thought - could bug 67907 (TAB key no longer working in TEXTAREAs) be
related to this?
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.
Depends on: 66285
QA Contact Update
QA Contact: bsharma → vladimire
Status: NEW → ASSIGNED
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...


Target Milestone: mozilla0.9.1 → mozilla0.9.2
this is a layout prob, though it may be hidden now by the tab focus shifting.  
bouncing back to rod
Assignee: jfrancis → rods
Status: ASSIGNED → NEW
reassigning
Assignee: rods → beppe
turns out this was intentionally done by blakeross@telocity.com.  See bug 47282.  
cc'ing interested parties.  Futuring until it's decided what we want here.
Target Milestone: mozilla0.9.2 → Future
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.
-->jfrancis
Assignee: beppe → jfrancis
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.
Assignee: jfrancis → mjudge
Component: HTML Form Controls → Selection
QA Contact: vladimire → tpreston
*** Bug 105661 has been marked as a duplicate of this bug. ***
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!
Attached patch one line change (obsolete) — Splinter Review
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.
kin, mike, dbaron... could one of you take a look at the patch?
I confirmed on 2002030607/Linux.
I hope this bug will be fixed by 1.0.

I'll post new patch.
Attached patch a new patchSplinter Review
Attachment #56696 - Attachment is obsolete: true
*** Bug 130496 has been marked as a duplicate of this bug. ***
*** Bug 132046 has been marked as a duplicate of this bug. ***
*** Bug 132825 has been marked as a duplicate of this bug. ***
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.
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=.
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?
Yes, it still counts as a review if you didn't do the patch.
This bug still frustrating in the mail edit window in RC2 (2002051006).  Any
chance this gets fixed for the real 1.0?
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.
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.
WFM in composer and message compose (2002 050908 on Windows 98).
Still broken in RC2 {2002051006} on Windows 2000 and Linux.
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.

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.
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
Keywords: mozilla1.0.1
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?
Hmmmm, just noticed mjudge's comment in comment 32.

mjudge, does that mean you're giving an r=mjudge?
shanjian, I think you know this code better than I do. are you willing to r= the
patch?
*** Bug 147002 has been marked as a duplicate of this bug. ***
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
Attachment #72915 - Flags: review+
Comment on attachment 72915 [details] [diff] [review]
a new patch

sr=kin@netscape.com
Attachment #72915 - Flags: superreview+
yeah i would have given it a review but i didnt know if i could r= my own bug. I 
will check this in.
Status: NEW → ASSIGNED
mjudge checked-in my patch into trunk.
I confirmed on 2002061808/Linux.
Status: ASSIGNED → RESOLVED
Closed: 19 years ago
Resolution: --- → FIXED
How about check-in to 1.0branch?
minusing for 1.0.1. we're going on the door w/ lots of annoyances, this will
have to be another.
Blocks: 156924
Removing the item for this bug from the release notes for 1.1beta and beyond.
Depends on: 140612
You need to log in before you can comment on or make changes to this bug.