Closed Bug 187083 Opened 19 years ago Closed 14 years ago

Arrow keys don't move cursor in text areas.

Categories

(Core :: Layout: Form Controls, defect)

defect
Not set
normal

Tracking

()

RESOLVED WORKSFORME

People

(Reporter: karl, Unassigned)

References

()

Details

(Keywords: qawanted, topembed+)

User-Agent:       Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 Chimera/0.6+
Build Identifier: Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.0.1) Gecko/20021220 Chimera/0.6+

Not sure why, but when I edit my photo album at mac.com I can't use the arrow
keys in the text areas. I tried to look under the hood but the textareas are in
an include file.

Reproducible: Always

Steps to Reproduce:
1. Create a photo page with mac.com
2. edit the page
3. try to move the cursor around in textareas with the arrow keys. Doesn't work

Actual Results:  
the cursor doesn't move

Expected Results:  
moved the cursor
QA Contact: winnie → petersen
Summary: arrow keys don't move cursor in text areas in mac.com photo edit pages ?? → arrow keys don't move cursor in text areas in mac.com photo edit pages
Whiteboard: qawanted
Looks like a duplicate of bug 180869.

Reporter:
In the textareas where you are not able to use the arrow-keys, are you also not
able to copy and paste text? Does switching to a different app, switching back
to Chimera, and refocusing (clicking on) the textarea fix the bug?
I have seen this problem on the linux build also(2003010808). Textarea and form
input fields did not allow the arrow keys to be used to move the cursor. I then
switched to Mozilla Mail and opened a new composer window and arrow key movement
was working correctly. I then switched back to the browser window and now the
textarea and input fields arrow key cursor movement worked. strange behavior.
karl@apologetix.com, can you still reproduce this problem using a current
nightly build? Can you also reproduce it using Mozilla?
Summary: arrow keys don't move cursor in text areas in mac.com photo edit pages → Arrow keys don't move cursor in text areas in mac.com photo edit pages
This has happened to me over the past couple of weeks.  Unfortunately, it's
seemingly random - I haven't been able to pin down a set of circumstances under
which it happens.  Nor is there a consistent site.  Sometimes it's when adding a
comment in Bugzilla, sometimes other places with text areas.  But most of the
time it works.  However, occasionally, all cursor keys cease to function and I
must use my mouse to click to another part of the text I'm entering...

Also, I'm using XP (currently 2003032808) so it's not just MacOS that's being
affected.  As I say, it started happening to me around 2 weeks ago.
Oh, and confirming bug as well as changing to All/All since we now have reports
from all 3 OSs.  Tweaking bug summary, since it's not limited to a single page.
 Additionaly, this is not Camino specific, but Browser in general.
Status: UNCONFIRMED → NEW
Component: HTML Form Controls → Layout: Form Controls
Ever confirmed: true
OS: MacOS X → All
Product: Camino → Browser
Hardware: Macintosh → All
Summary: Arrow keys don't move cursor in text areas in mac.com photo edit pages → Arrow keys don't move cursor in text areas.
Version: unspecified → Trunk
I just want to check something - when this happens, you're able to type
characters in the text area, but just the arrow key navigation is broken?
Correct.

Unfortunately, I haven't had this happen to me since I've been specifically on
the lookout for it.  I can't confirm or deny if copy/paste into the text works
(comment 1), although I *can* confirm that clicking on the textarea does not
help.  Also, either <End> or <PgDn> causes the browser window to jump down as if
I'd hit <PgDn> *outside* of the text area.  But, scrolling back up and putting
the cursor back into the textarea does not result in the cursor keys working. 
If it's actually <PgDn> doing this, my thought is that, for whatever reason, the
textarea is not receiving cursor focus, but is receiving focus for the purpose
of other key entry (typing).  However, I can't say for certain that it's <PgDn>
(rather than <End>), nor does that it makes much sense that textarea would
receive focus for only *some* keys and not others...  The next time it happens
to me again, I'll be sure to document this better.
I just ran into this when testing a patch and thought I'd comment on what can
cause it.  If the focus controller's mCurrentElement is not the same as the
EventStateManager's focused frame, then we could dispatch a key event to the
editor (which will receive character events fine), but the xbl commands that
move the caret won't locate the editor controller.
This just happened to me again, but I managed to break out of it (get it working
again) before I could confirm/deny of copy/paste worked.  However, I think I did
make a discovery.

When it happens, hitting <End> does indeed take you down a page (in the main
document, not the textbox), as if you'd hit <PgDn>.  Hitting <End> a second time
at that point does nothing.  (Hitting <PgDn> does the same thing, but hitting it
again, unlike <End>, actually *does* produce a further page scroll.  However see
below.)

After I'd experimented a bit with the difference between <End> and <PgDn> I
discovered that cursor keys were suddenly responsive in the textbox again (the
textbox in question was a Bugzilla comment).  So, I believe that one of the
following from within the textbox caused things to work again:  1) <PgDn>, 2)
<PgDn><PgDn>, 3) or <End><PgDn>.

If I could come up with some testcase where I could throw it into the behaviour
described here on demand, I'd actually be happier - that way I could clearly
give a complete list of symptoms and "workarounds" for when it does happen.
Aha!  It happened again (I can't believe I'm actually excited by having this bug
appear so I can do more testing...) and I have some more to report.

Copy/paste from within the textarea does not work.  You can highlight text, but
no copy option is then available from context menu - nor does using keyboard
shortcuts work.

However.  You *can* copy/paste so long as the text copied is from somewhere
else. Additionally, once you *have* pasted into the textarea, the cursor keys
are re-enabled (as is copy/paste within the textarea).  (I didn't get a chance
to determine if the text copied needed to be from a different application
altogether, a different tab/window, or just a different section of the page
you're on.)

So - if cursors don't work you can get them working again by either a
combination of <PgDn> and/or <End> (exact steps still not defined) or by pasting
some text in from somewhere else (again, required location of source text still
not clearly defined).
topembed nominating
Keywords: topembed
Discussed in edt.  Plussing.
Keywords: topembedtopembed+
Whiteboard: qawanted → qawanted,edt_b3
topembed-
Keywords: topembed+topembed-
> if cursors don't work you can get them working again by either a
> combination of <PgDn> and/or <End> (exact steps still not defined)
> or by pasting some text in from somewhere else

Unfortunately, I was hit by this again last night, and nothing I did as per the
above reinstated cursor movement to me.  I had to live without cursor movement,
using only the mouse, until I'd finished the post.  (Subsequent posts didn't
exhibit the bug.)

Has something recently regressed in terms of not being able to get the cursor
keys back at the time this happens?
I have no idea why I minused this... sorry. topembed+
Keywords: topembed-topembed+
I've run into this sometimes in Firefox 0.8.  Now I've hit this for the first
time in Firefox 0.9.  But what I noticed this time is when it happened there
were 2 carets in the broswer.  One was in the textarea and the other was in the
address bar.  And both were blinking.  I could not find a way to fix this in the
broswer like changing tabs.  Changing apps worked though.  And like the others I
don't know how to reproduce this.  This happened to me in the Mozillazine forums.
Keywords: qawanted
Whiteboard: qawanted,edt_b3
Using Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040616 and seeing
this bug several times per week, notably while contributing to
http://fr.wikipedia.org/
same here: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7) Gecko/20040615
Firefox/0.9
None of mentioned workarounds worked for me.
This is incredibly annoying! In 0.8 I barely noticed it, in 0.9 it was more
frequent, but I could almost allways fix it, and in 0.10 (or 1.0PR or whatever)
it has _worked_ (has been not broken that is) totaly 30 seconds in a week.

Btw, if I press and hold Shift, I can move the cursor, but when I release Shift,
it returns to where it were. Copy and paste works.
(In reply to comment #19)
> This is incredibly annoying! In 0.8 I barely noticed it, in 0.9 it was more
> frequent, but I could almost allways fix it, and in 0.10 (or 1.0PR or whatever)
> it has _worked_ (has been not broken that is) totaly 30 seconds in a week.
> 
> Btw, if I press and hold Shift, I can move the cursor, but when I release Shift,
> it returns to where it were. Copy and paste works.

I'm getting this problem in FireFox 1.0PR for Linux x86... Arrow keys will not
move the cursor within a textbox... They only function when holding the SHIFT
key, which just highlights text to be modified.

I've never had a problem with any of the previous builds; I'm going to recompile.  
Same for me. The arrow-keys also wont work in the address bar. Upgraded to
1.0_pre some minutes ago. Didn't ever have problems in previous firefox releases
Gentoo Linux has found a workaround in their bug database 
(http://bugs.gentoo.org/show_bug.cgi?id=64242) which worked for me: close 
Firefox, delete ~/.mozilla/firefox/default.<whatever>/compreg.dat. This file 
gets re-generated when Firefox starts up next time. 
I am totally and completely able to reproduce this but.  I recently emerged
1.0pre from Gentoo sources.  It wasn't until then that I had encountered this
bug.  I was unable to NOT experience this bug until doing the Gentoo work
around.  The bug has no mysteriously gone away.  Not sure if it will come back
again but will post if it does.
As per the gentoo workaround above, deleting the compreg.dat file, this solved
another bug.  I looked for it elsewhere but the most recent similar bug that I
could find (in a reasonable amount of time) was dated 2002.  My bookmarks
weren't being saved.  They would appear during the session in the bookmark menu,
but upon closing the application, they would disappear.  Having deleted the
compreg.dat file, bookmarks are now again saved beyond the session and are still
there during future session.  Two bugs worked around with one solution.  I like it!
Ok, now this is getting rediculous - removing the equivelant Thunderbird file
solved a problem of IMAP folders not being able to load, having constantly
displayed "Opening Folder".
I've been getting this bug for ages from when I started using Firefox 0.9.  Now
Firefox 1.0 is installed the same things happen:
- can't scroll in text boxes
- can't copy/ paste

However, additionally to previous comments, with the new find bar, I now see
that typing a ' or / in a text box turns the find bar on, so writing a newsgroup
message involves pressing escape after every ' or /

Have tried complete re-installs (all user info deleted etc.), and the problem
comes back.  Only thing that fixes it temporarily is pasting from an outside
application.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-GB; rv:1.7.5) Gecko/20041110 Firefox/1.0
*** Bug 302746 has been marked as a duplicate of this bug. ***
Another vote for fixing this bug. I've been running into it at irreproducible random times for the past year or so, arrow keys stop working, extremely irritating. It is among my top two bugs (the other being the poor clipboard format choice, bug 315370).
I can confirm that this bug still happens on 1.5.0.3 on WinXP.
I typically run into it about 15-20 times per day, but I suspect
that this can vary greatly depending on usage patterns and so on.
I do tons of Gooling and pasting stuff into forms all day.

Also see these bugs:
https://bugzilla.mozilla.org/show_bug.cgi?id=260290
https://bugzilla.mozilla.org/show_bug.cgi?id=256115
https://bugzilla.mozilla.org/show_bug.cgi?id=320088
https://bugzilla.mozilla.org/show_bug.cgi?id=337281
did the arrow key problem stop at some point? (prior to 2005?)
Assignee: bryner → nobody
QA Contact: chrispetersen → layout.form-controls
It regularily happens to me, usually in the address bar.
I am using Firefox 1.5.0.9 on Windows 2000.
It just happened.  Arrow keys didn not work.  Shift+arrow key or shift+end to select text did not work.  The cursor just didn't move.
By some switching to another app and opening a new page in a new tab the problem went away.

For me it is the #1 most irritating bug in Firefox.
Happened again.
(ref Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.0.9) Gecko/20061206 Firefox/1.5.0.9)

I did some experimenting:
- It seems to affect all text fields: input field, text area, or the URL bar itself.
- <-, ->, home, end, pgup, pgdn didn't work, with or without shift.
- the same functions on the numeric key pad also didn't work.
- I could enter text in Google search and delete it.  But <- and -> didn't respond.
- I could select text or move the cursor in a text field with the mouse.
- Up and Down arrows in a multi-line text area did not work.
- Funnily, up and down arrows in the text field on the Google Search page did work.  Arrow down opened a menu of previous entries and I could navigate between entries.
- I could tab and back-tab between fields.
- I could navigate between pages following a hyperlink or pressing a button, with the mouse, by using <enter> in a form, or using <space> on a hyperlink or button.  I could go to a page by selecting a bookmark in the menu.
- I could switch tabs with ctrl-tab or with the mouse.
- <- and -> worked in the menu bar.

After all the actions above the problem hadn't gone away.  I could do all these things but whenever in a text field, the <- and -> keys did not respond.

- when I opened a page in a new WINDOW then the arrows started responding.  I closed the new window and the problem was gone.  The arrows responded on the pages and fields where it didn't respond before.

I hope this is useful to locate the bug.
does it fail for you on trunk ftp://ftp.mozilla.org/pub/firefox/nightly/latest-trunk/

is this more likely to be an editor problem than forms?
I haven't tried the very last trunk.  I wouldn't be able to test it anyway, since I couldn't provoke the behavior.  It just happened randomly.  I did not visit mac.com.

But now that you ask, I haven't experienced the bug recently.  I am now running Firefox 2.0.0.12.  My environment: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8.1.12) Gecko/20080201 Firefox/2.0.0.12.

Is anybody still experiencing the problem with version 2?
Seems like a dead issue to me.
-> WFM
Status: NEW → RESOLVED
Closed: 14 years ago
Resolution: --- → WORKSFORME
You need to log in before you can comment on or make changes to this bug.