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

Status: RESOLVED DUPLICATE of bug 389768

(Firefox :: Keyboard Navigation, defect)

Description

[Tim Romberg]

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:

Comment 1

[Erik Johnson]

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.

Comment 2

[Jamie O'Keefe]

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.

Comment 3

[Jamie O'Keefe]

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.

Comment 4

[Ng Ming Hong]

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+

Comment 5

[John Leffingwell]

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.

Comment 6

[Steven Shelton]

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. 

Comment 7

[jerry asher]

I can confirm this happens to me on Windows XP on Firefox 1.0x as well as
Firefox 1.5 Betas 1 and 2.

Comment 8

[Ronan Waide]

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.

Comment 9

[Wayne Mery (:wsmwk)]

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).

Comment 10

[brian maniere]

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.

Comment 11

[Panos Stokas]

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.

Comment 12

[Joseph]

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.

Comment 13

[Wayne Mery (:wsmwk)]

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?

Comment 14

[Joseph]

(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.

Comment 15

[Antti Makkonen]

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.

Comment 16

[Shawn M. Jones]

I have collected all of the bugs that display these symptoms under Bug 389768.

Comment 18

[Justin [:JW_SoftvisionQA]]

(In reply to Shawn M. Jones from comment #16)
> I have collected all of the bugs that display these symptoms under Bug
> 389768.