textarea: unexpected cursor behaviour during arrow key navigation




11 years ago
8 years ago


(Reporter: Alexander Klauer, Unassigned)




Firefox Tracking Flags

(Not tracked)





11 years ago
User-Agent:       Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061205 Iceweasel/ (Debian-
Build Identifier: Mozilla/5.0 (X11; U; Linux i686; en-US; rv: Gecko/20061205 Iceweasel/ (Debian-

cursor column position is reset to 0 when arrow up/down keys are used, provided that current cursor column position is smaller than the length of the line below (arrow down) resp. above (arrow up) the current line.

Reproducible: Always

Steps to Reproduce:
1. Go to the indicated URL
2. In the text area, place cursor between the two closing curly braces ("}}") in line 13 or any other appropriate line
3. press arrow up or arrow down
Actual Results:  
cursor column position is reset to 0 (beginning of line)

Expected Results:  
cursor column position remains unchanged

Current software is rebranded to "Iceweasel" by my Linux distributor, but I believe the bug already occurred when it was still called "Firefox".
Duplicate of / related to bug 358361?
Depends on: 358361

Comment 2

11 years ago
I don't use TB, but judging from the description it quite seems so. So it's not a textarea bug, but a bug in the common edit widget used by several pieces of Mozilla software. I'm not familiar with this bug tracking system. Should I file a bug against some component (Toolkit component perhaps?) instead and mark this bug as a duplicate?

Thank you.
Let's keep this bug, since we're not sure it's a duplicate.

I'm moving it to Core/Selection for now. This seems to be Linux-only - I can't reproduce it on Mac, so I can't confirm it.
Assignee: nobody → selection
Component: Form Manager → Selection
Keywords: pp
Product: Firefox → Core
QA Contact: form.manager
Version: unspecified → Trunk
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv: Gecko/2007011004 BonEcho/
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.9a2pre) Gecko/20070112 Minefield/3.0a2pre ID:2007011204 [cairo]
I'd say it's a duplicate of bug #335810.
Assignee: selection → nobody
QA Contact: selection

Comment 6

8 years ago
Hi, the bug is gone, and has been gone for some time now. In all likelihood, it occurred due to bug #335810. So I'm closing my bug report. Feel free to reopen if this is not appropriate.
Last Resolved: 8 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.