Closed Bug 187083 Opened 19 years ago Closed 14 years ago
Arrow keys don't move cursor in text areas
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
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.
email@example.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).
> 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'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.
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 18.104.22.168 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 22.214.171.124 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:126.96.36.199) Gecko/20061206 Firefox/188.8.131.52) 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 184.108.40.206. My environment: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:220.127.116.11) Gecko/20080201 Firefox/18.104.22.168. 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.