It seems that pressing the End key when in a textarea removes the focus from the textarea. Might be a fallout from bug 258285 ?

This is just a textarea you can practice on.......

WFM, SeaMonkey 2005-08-18-03 on Linux

We don't lost focus when we typed "end" key. Please test following step: 1. Go to testcase(attachment 193140 [details]). 2. Set focus to textarea. 3. Press end key. 4. Press "4". 5. Press Ctrl + A(Select All). 6. Paste another editor(E.g., Search field). We can see the text is "testing: 123". However, we can see the text is "testing: 1234" in anoter editor. We cannot see all text in textarea. This is very serious problem.

> Might be a fallout from bug 258285 ? I don't think so. On 1.8 branch, this problem doesn't occour(bug 258285 is fixed on 1.8 branch in 16, Aug).

I can reproduced with 2005081906-trunk/WinXP.

Oops. Above comment is on seamonkey's buid ID.

OK: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050818 Firefox/1.6a1 NG: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050819 Firefox/1.6a1 http://bonsai.mozilla.org/cvsquery.cgi?treeid=default&module=MozillaTinderboxAll&branch=HEAD&branchtype=match&dir=&file=&filetype=match&who=&whotype=match&sortby=Date&hours=2&date=explicit&mindate=2005-08-18&maxdate=2005-08-19+06%3A00%3A00&cvsroot=%2Fcvsroot

I see this too (Camino from today) but with an additional flaw: everything you type after "end" will be backwards! Steps to reproduce: 1. Go to testcase(attachment 193140 [details] [edit]). 2. Set focus to textarea. 3. Press end key. 4. Type "123". 5. Select All, Copy, and then Paste. Expected result: testing: 123123 Actual result: testing: 123321

Aaron, could this have been caused by bug 291077 , the initial patch wasn't checked in on the branch. Also, bug 305239 seems like it might be related to this bug.

I loaded attachment 193140 [details], set focus to textarea, pressed end key, typed in "123", selected all, copy, then paste and I got the expected results. Seamonkey 1.0a rv:1.9a1 build 2005081805 under XP Pro SP2. WFM

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

(In reply to comment #9) > Aaron, could this have been caused by bug 291077 , the initial patch wasn't > checked in on the branch. No, that code is only run when a screen reader or other software tool for users with disabilities is being used alongside Firefox.

OK, this was, like bug 305239, caused by my patch to bug 16311, so Taking. I'll be able to work on this tomorrow.

This is really the same as 305239. Since that bug has a blocking flag and more comments and CCs, I attached the fix to that one and I'm duping this one to it. Caleb - thanks for finding this, and I apologize for initially not taking responsibility for it. *** This bug has been marked as a duplicate of 305239 ***

verified dup