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?

reassigning

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

*** 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

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.

QA Contact Update

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...

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

reassigning

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.

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

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.

*** 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!

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.

*** 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

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

Comment on attachment 72915 [details] [diff] [review] a new patch sr=kin@netscape.com

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

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

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.

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