Closed Bug 305183 Opened 15 years ago Closed 15 years ago

Focus lost in textarea when pressing "End"

Categories

(Core :: DOM: UI Events & Focus Handling, defect, major)

defect
Not set
major

Tracking

()

VERIFIED DUPLICATE of bug 305239

People

(Reporter: bugs.caleb, Assigned: uriber)

References

Details

(Keywords: regression, testcase)

Attachments

(1 file)

127 bytes, text/html
Details
It seems that pressing the End key when in a textarea removes the focus from the
textarea.

Might be a fallout from bug 258285 ?
Attached file testcase
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.
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).
No longer blocks: 258285
I can reproduced with 2005081906-trunk/WinXP.
Oops. Above comment is on seamonkey's buid ID.
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?
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.
Keywords: helpwanted
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
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
Closed: 15 years ago
Resolution: --- → DUPLICATE
verified dup
Status: RESOLVED → VERIFIED
Flags: blocking1.9a1?
Component: Keyboard: Navigation → User events and focus handling
You need to log in before you can comment on or make changes to this bug.