Closed Bug 264037 Opened 20 years ago Closed 9 years ago

Edit text boxes don't react to navigation keys (up+down arrow, home, end), cut&paste

Categories

(Firefox :: Keyboard Navigation, defect)

1.0 Branch
x86
Windows 2000
defect
Not set
major

Tracking

()

RESOLVED DUPLICATE of bug 389768

People

(Reporter: romberg, Unassigned)

References

Details

(Keywords: regression, Whiteboard: workaround comment 12)

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 Build Identifier: Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20041001 Firefox/0.10.1 I'm sorry I can't give a step by step reproduction yet, because it doesn't happen very often, but it happened at least twice, and on different pages. To compensate, I'll describe as exactly as possible so the code might be easily identified. After working normally many times, at one moment many opened edit boxes "go on strike" with respect to cursor keys, copy/cut&paste (both using shortcuts Ctrl-C and using popup menu). Last time, this affected the Search box (Google) in the toolbar, the URL box and a multiline form field opened on one page (they went on strike together). Copy really did not work, i.e. Paste in a different application pasted the previous clipboard content, while Paste in Firefox did not do anything. All Navigation keys did not work, i.e. Cursor, Home/End and Enter keys. But normal Text could be entered, and the caret could still be positioned using the Mouse. Finally, I found one text box on the page in a different tab (the search box on top of a Google result page - not the search box on the toolbar, like above) which "broke" the strike, i.e. it worked, and after I used those keys inside it, the other edit boxes worked normally again as well. To me, it sounds as if I managed to have another component swallow those keys (but it must be something above page level, possibly the Find bar?) until the strikebreaker text box managed to reclaim them. Reproducible: Couldn't Reproduce Steps to Reproduce:
I'm experiencing this behavior as well, although it's with Gecko (the embedded version). I get it when one window (with a form) launches another, modal window (with a form). When I select text in the second window, press Ctrl-C, and then close the 2nd window, all the text fields in the first window no longer respond to cut and paste actions; additionally, they don't respond to Home, End, or arrow keys.
I see this problem as well. It definitely occured with Firefox 1.04, and maybe 1.03. I also allowed Windows XP to update itself around the same time, so the problem may be related to either or both changes. I also have MSVDM (http://www.microsoft.com/windowsxp/downloads/powertoys/xppowertoys.mspx) installed to get four virtual windows and I noticed that it when I switch from one virtual window to another, I cannot type anything into an edit window that had my cursor until I clicked into the window. Even when I click, and after editing in the textfield, the home, arrow, shift-arrow keys and cut/paste stop working. MS Word does not exhibit this problem. I am using Windows XP Professional 2002 SP 2 Build 2600.
Resizing the window seems to clear it up for me until I switch to the next window. I have noticed that Thunderbird (1.0) sometimes encounters this problem, as well.
Happens to me too on Deer Park Alpha 2 under WinXP. When I use Deer Park Alpha 1 / Firefox 1.0.x, there were no problem. Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+
Firefox version 1.5 Beta 1 Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4 I also have this occasional problem affecting some editing keys and clipboard functions. These keys do not work inside edit boxes, either HTML or in the application: Left and Right arrows, Up and Down arrows (in multiline edit boxes), Home, End. In single line edit boxes Up and Down arrow keys are correctly passed to other controls. These editing keys work fine: Insert, Delete, Backspace. Copy, Cut and Paste keys do not work: CTRL-C, CTRL-X, CTRL-V Copy, Cut, Paste, Delete menu commands are NOT selectable, even outside of edit boxes as long as the problem persists. If the edit box problem is corrected (see below), the clipboard menu commands become selectable. Select All menu command and keyboard command CTRL-A does not seem to work inside or outside of edit boxes. When invoked, although nothing seems to happen, it does allow the Copy menu command to now be selected. HOWEVER, the command, when selected or typed, does not actually copy anything to the clipboard. It happens semi-consistantly when a new instance of the browser opens with: 1. a shortcut from the desktop (only sometimes) 2. a search from Google Deskbar 0.5.95 Beta (every time) Opening new instances of the browser from within Firefox works as expected, even when launched from an affected instance. Changing focus from and back to the browser window fixes all of these problems.
Firefox 1.5 Beta 2; Windows XP The problem seems to have gotten worse in Beta 2, as I now encounter this bug almost every single time I try typing in a textarea.
I can confirm this happens to me on Windows XP on Firefox 1.0x as well as Firefox 1.5 Betas 1 and 2.
Adding a 'me too': Windows XP Pro, Microsoft Virtual Desktop Manager (MSVDM), Firefox 1.5. I think MSVDM may possibly be involved in the problem as it manifests after switching desktops. If I minimize Firefox and maximize it again, cut and paste behaves correctly.
regession is suggested in comment 4, i.e between Deer Park Alpha 1 and Deer Park Alpha 2 - presumably between _something_ and 20050712 can you give a URL example where this currently happens? (maybe https://bugzilla.mozilla.org/show_bug.cgi?id=264037 ?) bug 228476 and bug 259007 may be same bug and are older. (but there are also many, more contemporary open nagivation and cut&paste bugs).
Assignee: bross2 → nobody
Severity: normal → major
Component: General → Keyboard Navigation
QA Contact: general → keyboard.navigation
Summary: Edit text boxes don't react to navigation keys, cut&paste → Edit text boxes don't react to navigation keys (up+down arrow, home, end), cut&paste
Whiteboard: regression
just confirming this bug still exists in the latest official release (1.5.0.4) and it's really annoying. Actually I'm finding it to be even more widespread, and to affect also the arrow kes on a PC. I would say it happens to me at least once a day on average. I found a workaround on the mozillazine forums -- if you hit F1 to set the focus on a new window, the problem goes away once you bring focus back to the original brower window. I haven't tested this extensively, but it worked just now, the latest time I ran into this bug. This is a major usability issue that I'm sure turns off a huge number of users, so I hope it gets the prompt attention that it deserves. See Bug 314683 for a probable duplicate.
I have this problem too. I can't reproduce it, it happens randomly. The workaround provided at comment #10 works for me, so it might offer some valuable ideas on the root of the problem.
Same here, this is definitely a problem. I am using Mac OS 10.4.8, Firefox 2.0.0.2 and have an issue with the up and down arrows (no other keys it seems). The error can be corrected by removing focus from the form input and re-focusing into it, but otherwise they keys do not work.
cut&paste may be different issue(s), some of which have been fixed I'm wondering if it is incorrect that this is a regression. Did anyone never see this prior to version 1.0?
Keywords: regression
Whiteboard: regression → workaround comment 12
Version: unspecified → 1.0 Branch
(In reply to comment #12) > Same here, this is definitely a problem. I am using Mac OS 10.4.8, Firefox > 2.0.0.2 and have an issue with the up and down arrows (no other keys it seems). > > The error can be corrected by removing focus from the form input and > re-focusing into it, but otherwise they keys do not work. > Preface to the problem: I am using an AJAX interface, so the input is of type <textarea> and is loaded when clicking a link that looks like: <a href="#" onclick="new Ajax.Updater('div_id_number', '/manage/stuff_to_do', {options}); return false;">click me</a> That textarea that is returned to me is a container that already contains text inside of it, returned to me from a database. I need to be able to edit this pre-existing information in the <textarea> tag, so it is essential that the cursor keys work. Again, the right and left arrows work perfectly, it is only the up and down. It very rarely happens, but steps to reproduce: - Click on a [an AJAX] link to arrive at a pre-filled <textarea> input. - Click inside of the <textarea> box, anywhere to put the cursor inside (there is no JavaScript that auto-focuses for me). - Either immediately begin typing, then using the navigation keys after some swift strokes on the keyset, or simply attempt to use the navigation keys immediately.
I have the same behaviour quite frequently when I make these steps with MSVDM and windows-xp with latest updates (24.7.2007). I have not seen this behaviour in Ubuntu and Firefox. 1. Open firefox in one screen(1). 2. Open antoher firefox in second screen(2). 3. Open some random tabs in 2. (Leave focus on firefox address bar or some form in tabs web page) 4. Switch to screen 1 and focus on firefox. 5. Switch back on screen 2. Expected result: Arrowkeys and cut-copy-paste functions are working on focused browser 2. Actual result: Now the paste and arrow keys will not work. Also if you had some text painted in the browsers (2) web-page you cant copy or cut it.
I have collected all of the bugs that display these symptoms under Bug 389768.
(In reply to Shawn M. Jones from comment #16) > I have collected all of the bugs that display these symptoms under Bug > 389768.
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → DUPLICATE
You need to log in before you can comment on or make changes to this bug.