Focus lost in textarea when pressing "End"

VERIFIED DUPLICATE of bug 305239

Status

()

Core
Keyboard: Navigation
--
major
VERIFIED DUPLICATE of bug 305239
13 years ago
12 years ago

People

(Reporter: Caleb, Assigned: Uri Bernstein (Google))

Tracking

({regression, testcase})

Trunk
regression, testcase
Points:
---

Firefox Tracking Flags

(Not tracked)

Details

Attachments

(1 attachment)

127 bytes, text/html
Details
(Reporter)

Description

13 years ago
It seems that pressing the End key when in a textarea removes the focus from the
textarea.

Might be a fallout from bug 258285 ?
(Reporter)

Comment 1

13 years ago
Created attachment 193140 [details]
testcase

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

Comment 2

13 years ago
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.
Severity: normal → major
> 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).
(Reporter)

Updated

13 years ago
No longer blocks: 258285
I can reproduced with 2005081906-trunk/WinXP.
Oops. Above comment is on seamonkey's buid ID.

Comment 8

13 years ago
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

OS: Windows XP → All
Hardware: PC → All
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.
Flags: blocking1.9a1?

Comment 10

13 years ago
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

Comment 11

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

Comment 12

13 years ago
(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.

Updated

13 years ago
Keywords: helpwanted
(Assignee)

Comment 13

13 years ago
OK, this was, like bug 305239, caused by my patch to bug 16311, so Taking. I'll
be able to work on this tomorrow.
Assignee: aaronleventhal → uriber
Keywords: helpwanted
(Assignee)

Comment 14

13 years ago
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 ***
No longer blocks: 305239
Status: NEW → RESOLVED
Last Resolved: 13 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED

Updated

12 years ago
Flags: blocking1.9a1?
You need to log in before you can comment on or make changes to this bug.