Closed Bug 220900 Opened 21 years ago Closed 17 years ago

Focus breaks, cut/copy/paste and other focus-dependent tasks broken

Categories

(Core :: DOM: Editor, defect)

Product:
Core
Component:
DOM: Editor
Type:
defect
Priority:
Not set
Severity:
major

Tracking

()

Status:
RESOLVED FIXED

People

(Reporter: mozilla.org, Assigned: oliver_yeoh)

References

(Blocks 2 open bugs)

Details

(Keywords: conversion, regression, verified1.8.1.1, Whiteboard: [Steps to reproduce in comment 185] Workarounds see comment #145)

Attachments

(3 files, 1 obsolete file)

hardware specs for my 100% "bug is reproducable" environment.
1.69 KB, text/plain
Details
Patch for windows
2.55 KB, patch
MatsPalmgren_bugz
: review+
robert.strong.bugs
: review+
brendan
: superreview+
dveditz
: approval1.8.1.1+
Details | Diff | Splinter Review
Additional xpfe patch for windows
1.62 KB, patch
brendan
: review+
brendan
: superreview+
dveditz
: approval1.8.1.1+
Details | Diff | Splinter Review 
User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1) Gecko/20021130
Build Identifier: Firebird 0.6.1

On about 1 out of 10 pages, the Copy command on the edit menu is grayed out, and
the kbd shortcut doesn't work either.  Sorry, can't reproduce it, but it happens
often.

Context: Many Firebird windws open (often a couple of dozen)

When this happens, the mouse wheel doesn't work either. (to be reported next). 
Strictly speaking, I can't be sure that when one happns, the other does too
(because I don't test every page I see) but when one becomes apparent, I test
the other also.

Reproducible: Couldn't Reproduce

Steps to Reproduce:
1.
2.
3.
See above discussion of irreproducibility.
Actual Results:  
Firebird doesn't put the highlighted text in the Windows paste buffer.

Expected Results:  
Firebird should put the highlighted text in the Windows paste buffer.
I've also experienced this bug. Happens daily, but intermittently. Copy command
on context menu is still available, but text does not copy to clipboard. KB
shortcut does not work either. Only way of moving text is to drag & drop it.
Mouse scroll wheel still works as expected.
Occurs in Address bar, and viewport.

Windows 2000 (SP4)
User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.5)
Gecko/20031007 Firebird/0.7

i can confirm it too, with WinXP Pro, SP1 (posted it <a
href=http://forums.mozillazine.org/viewtopic.php?p=393566>there</a> already)
it happened on FB 0.7 and 0.8, but only once in a month or so:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.5) Gecko/20030925
Firebird/0.7 and 
Mozilla/5.0 (Windows; U; Windows NT 5.1; de-DE; rv:1.6) Gecko/20040206 Firefox/0.8

Both of them on the same PC, but with a different Profile

The strange thing is, that opening the help/about box and closing it fixed it
*** Bug 233255 has been marked as a duplicate of this bug. ***
-> Confirming

If anyone can provide simple instructions or a testcase to reproduce this every 
time, it would be greatly appreciated.
Status: UNCONFIRMED → NEW
Ever confirmed: true
OS: Windows 2000 → Windows XP
Summary: copy/(paste) intermitten breakage (correlates w/ mouse-wheel problem) → Copy/paste intermittent breakage (correlates w/ mouse-wheel problem)
To reproduce on Windows XP:

1) Open multiple tabs.
2) Select location box text in tab (a)
3) Copy
4) Verify it pasteable in another app
5) Switch to tab (b)
6) Select location bar text
7) Copy
8) Verify text is NOT pasteable in another app
9) Verify that it is impossible to copy/paste any text from the browser
10) Verify that selecting/copying text in another app resets conditions

Tested with: FireFox v0.8
Tested on: Windows XP SP1
In OSX, it reproduces in the following procedures.

  0) Restart firefox.

(In reply to comment #5)
> 1) Open multiple tabs.
> 2) Select location box text in tab (a)
> 3) Copy

  4) Verify text is NOT pasteable in another app

Mac OS X 10.3.3
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; ja-JP; rv:1.7b) Gecko/20040322
Firefox/0.8.0+

Since it is checking that this problem is reproduced also by OS X, "OS" and
"Hardware" are changed into ALL.
OS: Windows XP → All
Hardware: PC → All
i can confirm this bug as it is described here:

http://forums.mozillazine.org/viewtopic.php?t=60635

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040331
Firefox/0.8.0+

Windows 2000 SR-4 german
Flags: blocking0.9?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040411
Firefox/0.8.0+ (MozJF/SVG)

While editing my forum messages a lot I noticed the following:
All of a sudden (unclear why), I cannot copy/paste or move the cursor with the
errors inside a textbox, I can only place it somewhere (in that box).
When I rightclick -> "select all" it will select everything on that page except
what's in the textbox , the same behaviour happens when using ctrl+A.
Somehow the textbox content appears to be excluded for the select option.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7b) Gecko/20040411
Firefox/0.8.0+ (MozJF/SVG)

While editing my forum messages a lot I noticed the following:
All of a sudden (unclear why), I cannot copy/paste or move the cursor with the
errors inside a textbox, I can only place it somewhere (in that box).
When I rightclick -> "select all" it will select everything on that page except
what's in the textbox , the same behaviour happens when using ctrl+A.
Somehow the textbox content appears to be excluded for the select option.
not critical enough to block 0.9, which is focused on feature complete, bug
squashing is during the 0.9 to 1.0 buildup, especially before 1.0beta

This sounds like focus is being stuck into a non-textarea element somehow.  Can
be this reproduced on a totally clean build+profile (no extensions etc, I have
seen focus issues with certain extensions like TBE in the past that do bad
things with mouseclicks)
Flags: blocking0.9? → blocking0.9-
QA Contact: mconnor
Flags: blocking1.0?
Flags: blocking1.0? → blocking1.0+
Only head Firefox developers and a few other people can set the flag to
blocking1.0+.  If you think it should block, set the flag to blocking1.0? and a
dev or appropriate person will evaluate your request.
Flags: blocking1.0+ → blocking1.0?
I'm getting the same bug on Mozilla 1.7 RC 1, Windows XP (have not experienced
it on Linux so far). Selected text cannot be copied with Control+C or menu.

Also, something that may be interesting to try, I often have a lot of tabs open.
When this bug strikes, it is (every time I tried) still possible to use "select
all" from the right-click menu. Then a copy command can work, but it will select
text and copy it from a different tab than the one currently open. The text on
that tab will be highlighted when you switch to it. After pasting this text
somewhere (a whole page from a different tab), correct copying behaviour becomes
available again.
Most likely focus related. -ing without a test case.
Flags: blocking1.0? → blocking1.0-
Flags: blocking1.0- → blocking1.0+
fmannino@euristic.it, do not change blocking flags a dev already set.
Flags: blocking1.0+ → blocking1.0-
In case it's any help finding the root of the problem, Thunderbird 0.6 (and for
several versions before) exhibits the *exact* same problems in the mail compose
window, so the problem is likely in a shared component both Firefox and
Thunderbird have taken from Mozilla.
some of the pattern is described in
http://forums.mozillazine.org/viewtopic.php?t=60635
I have been able to reproduce some copy/paste issues (however, only slightly
consistently).  I am currently using Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.7) Gecko/20040721 Firefox/0.9 (MOOX-AV) but I was able to reproduce
this with 0.9.2 official zip build (haven't tried the installer yet).

This is how I am able to reproduce the breakage:
1. Open a Firefox window and goto any webpage (doesn't matter, just to get a URL
in the address bar).
2. Highlight the URL in the address bar.
3. Press Ctrl+C three times

Now the clipboard contains no data, apparently FF overwrote nothing into the
clipboard.  This also seems to break the ability to copy text from other parts
of FF (notabily this textbox).  This SEEMS to only happen consistently when
copying from the address bar.  Restarting FF temporarily restores full
copy/paste functionality (until three copies are done from the URL bar).  I am
able to reproduce this every single time on both of the builds mentioned earlier
using completely clean profiles (no extensions or anything, deleted the
documents and settings\....\Mozilla directory entirely).  I am running Win XP
SP1 on a P4 2.4Ghz machine with 1GB of ram.

However, I am NOT able to reproduce this AT ALL on my P3 750Mhz laptop with
256MB of ram.
The "Ctrl+C three times" method must be specific in some strange way to that
computer. On all four of my machines (three XP, one OS X) with 0.9.2 this is not
reproducable. I will admit that two of my XP machines do experience copy/paste
breakage from time to time, but it's probably only those two since those are my
main systems (which in turn get used a lot), and this is simply so random a problem.
I figured it would be difficult to find others that were able to reproduce this
as easily as I could.  What I am wondering is if there would be a way to make a
special debug build that might allow me to track some of the clipboard functions
to possibly narrow this problem down since I am able to reproduce this consistently.
(In reply to comment #20)
> What I am wondering is if there would be a way to make a  special debug build
> that might allow me to track some of the clipboard functions to possibly
narrow > this problem down since I am able to reproduce thisconsistently.

See under the Debug Build heading of
http://www.mozilla.org/projects/firefox/build.html
I have found with Windows Firefox, if I have a RDC window open (remote desktop),
copy/paste fails.  If RDC is closed, it works.
This has been driving me crazy for many releases.  Obviously it is a problem,
but hard to fix when it's so intermittent.  Does anybody know what we should be
looking for in a debug build to help track the problem down?
Note this also happens with Cut (I'd mark it dataloss if it wasn't for Undo
still working)
Summary: Copy/paste intermittent breakage (correlates w/ mouse-wheel problem) → Cut/copy/paste intermittent breakage (correlates w/ mouse-wheel problem)
I'm trying to duplicate breakages since 1.5 years and sofar no luck.
The only thing I've been able to single out is that in only happens in multi-tab
windows and never in a single-tab window.

In the last 2~3 weeks AVIARY nighlies the problem has been occuring far less
often than before. (~20% of what I had before)

Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7) Gecko/20040727
Firefox/0.9.1+
simple confirmation of this: i see it in both firefox and thunderbird
confirmed. XP SP1, SecureCRT and Firefox 0.9.2 (i know, one ver behind). In 
SecureCRT, highlight a URL, 'cut', tab to Firefox, then ctrl-t or click
"new tab", attempt to paste. I confirmed that my cut worked by pasting to
another application before tabbing to Firefox, which then drops it frequently.

This does not happen 100% of the time, and I can't figure out what affects 
this beyond the above. 
To build on Adam M's note:  Today I could not copy from the address bar (tried
to copy/paste/copy from browser pane, -- nothing).  I remembered this comment
about Remote Desktop  so I closed all the open RDP clients and the copy from the
address bar immediatly worked.

Do others with this problem also use RDP at the same time?
I *do* use RDP, yes.  Whether this bug shows up *only* while using RDP, I shall
have to test.

On a side note, i've found that doing help->about, then reselecting the text,
then copying seems to work fairly consistently.
happens with FF-only open aswell
Normally ,if I have the problem, it happens after I open FF the first time , use
open in tabs (some 12 bookmarks), and try to edit a forum message.
Easy workaround:
After I open the editpage and find out it does not work I open the same editpage
in a new window.
After the the first on (in the tabbed window) works.
It looks like a component is not always loaded when you use open in tabs.

The problem which a copy does not commit correctly is well generated, when
copying build ID on the About screen of Thunderbird.

Mac OS X 10.3.5
version 0.7+ (20040818)

In the last couple of months I see this problem quite frequently - both with
Seamonkey and Firefox. Today I noticed another phenomenon: Trying to paste text
in one field (New bug/URL) persistently pastes it in another (New bug/Summary).
I managed to overcome this by dragging the text out to Wordpad, re-copying it to
the clipboard from there, and pasting it in Firefox.

Prog.


I never experienced these copy & paste and keyboard problems until I installed
Mozilla/5.0 (Windows; U; Windows NT 5.0; rv:1.7.3) Gecko/20040913
Firefox/0.10.1. Since then I regularly can't copy & paste text or use the arrow
keys, as mentionned in my additional comment to bug 258128. Shouldn't that bug
marked as a duplicate of this one ?
To sum things up, I searched for « copy paste » bugs and found bug 258128, this
one and bug 238344. As this one is the oldest, I think the others should be
marked as duplicates, like bug 233255 is.

Last but not least I should also mention that the copy & paste problem only
happens in Firefox, if I copy a text from Firefox and try to paste it to a text
editor (Notepad under Windows), it works. It means the text is copied to the
clipboard. So it can't be pasted to text fields, in forms, nor to the address or
search bars.
*** Bug 258128 has been marked as a duplicate of this bug. ***
Steps to Reproduce, taken from Bug 258128:

1. Open www.mozilla.org/ports/os2
2. Open link 'current open warpzilla bugs' in a new tab

Result: Copy/paste is disabled. Moving the caret with the keyboard is also
non-functional.

Prog.
Whiteboard: Steps to reproduce in comment #35
Severity: normal → major
I've just tried the steps mentioned in #35 7 times in a row. This never
occurred. I appreciate the severity (at least as far as the annoyance level) of
this bug, but it seems there is still no guaranteed test case for this problem.

I'm using build Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3)
Gecko/20041011 Firefox/0.10
Whiteboard: Steps to reproduce in comment #35 → Steps to reproduce in comment #35 (intermittent)
Ok, I've run some more tests:

Bug is always reproducible (using comment #35 steps) with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20040919
Firefox/0.10
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a4) Gecko/20040925

Not reproducible with:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041011
Firefox/0.10

Prog.
...and some more:

No problem in:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.4) Gecko/20041011
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8a5) Gecko/20041017

This was definitely broken in rv:1.8a4/Gecko/20040925, but seems fine in more
recent builds.

I'm very close to marking this WORKSFORME, any other testers want to share their
findings?

Prog.
Hiya,

I've been watching this bug for a while now, and I'm quite happy to see the
recent activity because it's *VERY* annoying.  I love firefox/thunderbird, but
this really cuts down on that love.  I've not been able to get this
consistently; I'll try this later today.

I'm running 1.0PR - should I be testing with a nightly?  Also, somebody
mentioned terminal services client making a difference with this.  I'm
constantly running terminal services client on a multi-monitor system.  What
about extensions?  I suppose I ought to disable them all before testing?

thanks,
-kz
(In reply to comment #39)
> I'm running 1.0PR - should I be testing with a nightly?

If you wish to help testing this, definitely. The latest Firefox/Aviary
nightlies can be found here:
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/

> Also, somebody
> mentioned terminal services client making a difference with this.  I'm
> constantly running terminal services client on a multi-monitor system.

I don't think it's related. I see this regardless of terminal services.

> What about extensions?  I suppose I ought to disable them all before testing?

With recent nightlies, they'll get disabled anyway. If you wish to be on the
safe side, run "firefox.exe -p" and create a fresh profile for testing.

For questions not directly related to this bug, please post in
http://forums.mozillazine.org

Prog.
Here's my initial test (reproducable).  Now grabbing a nightly for more testing.
-kz

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1

- www.mozilla.org/ports/os2
- right click/copy link location on "Current Open Warpzilla Bugs"
- start->Run and paste
  * sometimes nothing pastes, sometimes it works at this point
- click address bar
- everything is selected
- ctrl + c (for copy)
- start->Run and paste
  * sometimes nothing pastes, sometimes it works at this point
- repeat steps other than the first one above (copy link location, paste,
address bar, ctrl + c, paste)
** always is broken by the end of the second iteration


- click address bar
- everything is selected
- ctrl + c (for copy)

What i mean when i say "everything is selected" is that the initial click on the
address bar selects the entire url.  So a single left click, followed by a Ctrl
+ C key stroke.

Just thought i should clear that up.
I've repeated this with the .zip version found at
http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/latest-0.9/.  18-Oct-2004
10:47   6.2M.  For some reason Help->About still shows "Mozilla/5.0 (Windows; U;
Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1"

It broke on the first part of the second iteration.  So "Copy Link Location",
Ctrl + C in address bar, and "Copy Link Location" will result in a paste not
working in start->Run.  (note that pastes also fail in notepad, for the record)
*** Bug 238344 has been marked as a duplicate of this bug. ***
*bump*

anybody else able to create this problem with my steps?  or am I losing it?

-kz
(In reply to comment #45)
> *bump*
> 
> anybody else able to create this problem with my steps?  or am I losing it?
> 
> -kz


oh hell yea i can reproduce the heck out of it with your step, and with most of
the steps here.  it's the oddest thing because we all can't do something that
-always- triggers it.  while you and i can make it jump with this, some guy in
toledo is trying it and it aint doin nothin.

i swear,  this one bug is going to drive me insane,  because it always happens
right when i need it not to.   aye aye!
I've just gone through this about 11 times with "Mozilla/5.0 (Windows; U;
Windows NT 5.1; en-US; rv:1.7.3) Gecko/20041020 Firefox/1.0", still not happening.

The randomness of this bug is truly infuriating.
gah!  same here.  right when i'm thinking "i've gotta pass this url off to a
friend!!!" and bam! doesn't work.

Makes me think maybe it's something to do with the version of windows or
interference with other software.  I shall test for this by closing other
programs and testing on other operating systems to see if i can *NOT* get it ever.

Thanks,
-kz
wfm, although I remember some copying failures in the past. But I still see
occasional failures to copy from Windows Notepad (under Win2K) to other apps.
Which makes me wonder whether the issue here is a general Windows clipboard
problem. Probably not for the original reporter, though.
And a question for keith :  is there any error displayed in javascript console ?
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041021 Firefox/1.0

wfm too (a.t.m.)

I have seen this problem on Mozilla/Firefox on MacOSX so it is not
Windows-specific.  I'm sorry I haven't had a chance to test a daily build with
the latest steps to see if I could reproduce it.

I believe there is a focus problem that is causing the problem because other
things didn't work either (e.g. command-T didn't give me a new tab).
Oh, also, there isn't anything related to this problem on the JS Console when
I've had this problem.
I haven't previously been able to reproduce this bug, but the steps in #35 work
every time for me:

1. Open www.mozilla.org/ports/os2
2. Open link 'current open warpzilla bugs' in a new tab

Result: Copy/paste is disabled. Moving the caret with the keyboard is also
non-functional.

Opening step 1 in a different window to the one you're currently in restricts
the copy/paste problem to that window only - and when that window is closed, you
can re-launch it and experience the bug once again by following the steps - all
without closing the original process.

More importantly, I've discovered that step 2 (opening a link in a new tab) only
causes the bug on certain urls. On the page suggested, only the two bugzilla
pages cause the bug to appear - those are  Current Open Warpzilla Bugs
(http://bugzilla.mozilla.org/buglist.cgi?bug_status=UNCONFIRMED&bug_status=NEW&bug_status=ASSIGNED&bug_status=REOPENED&op_sys=OS%2F2&order=Bug+Number)
and  Recently Changed Warpzilla Bugs
(http://bugzilla.mozilla.org/buglist.cgi?query_format=&op_sys=OS%2F2&order=Bug+Number&chfieldfrom=15d&chfieldto=Now&cmdtype=doit).

All other links don't invoke the bug. The differences I can see obviously with
these two pages are: 
1) query string on url (but the google links work fine, and they use a query string)
2) The html uses 'server push technology' (take a look at the source)

Probably a long shot, but maybe it'll help someone - this bug is seriously
preventing me from using Firefox full time!
fwiw, i cannot reproduce this on WinXP at all, SP1 or SP2.

User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913
Firefox/0.10.1
Actually, that makes a fair bit of sense.  If focus gets horked, as I've seen
from time to time, then that would make a lot of sense.  Short version is that
focus in Moz sucks in some cases.
Summary: Cut/copy/paste intermittent breakage (correlates w/ mouse-wheel problem) → Focus breaks, cut/copy/paste and other focus-dependent tasks broken
(In reply to comment #54)
> fwiw, i cannot reproduce this on WinXP at all, SP1 or SP2.
> 
> User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913
> Firefox/0.10.1

Ah, but I can, and have reproduced it plenty of times, with your setup, and so
you see the pointlessness of posting generic WFM's in a bug report of a bug that
is so intermitant and unpredictable.

Is there no option in Firefox, or plugin we can use, to make an "debug image" of
the state it is in whenever copy/paste/etc goes awry?  Because, once this bug
shows itself, you are stuck until you close out the browser.  We should have
something along the lines of how the Quality Feedback Agent sends data about a
crash, except you could send the data whenever a specific bug occurred, and send
the data to a database, organized by Bug number on Bugzilla.
The only problem I see is that I am sure you guys have already run Firefox in
its debug mode, and STILL couldn't figure this one out...
It seems, on my XP system, that the bug does not occur when I open one terminal
services session... but it occurs persistently and reliably if I open a second
termsvcs session (incidentally [?] to yet another windows server).  If I close
one of the two ts sessions, copy/paste works when I copy a link location and
paste it as text, but I cannot copy text displayed on screen.  Only when I've
closed the second ts session can I copy/paste displayed text again.

Seems repeatable.  Confirm? 

Mozilla/5.0 (Windows; U; Windows NT 5.1; rv:1.7.3) Gecko/20040913 Firefox/0.10.1
Thunderbird version 0.8 (20040913)
Windows XP (v5.1 build 2600.xpsp2_gdr.040517-1325 service pack 1)
(In reply to comment #35)
> Steps to Reproduce, taken from Bug 258128:
> 
> 1. Open www.mozilla.org/ports/os2
> 2. Open link 'current open warpzilla bugs' in a new tab
> 
> Result: Copy/paste is disabled. Moving the caret with the keyboard is also
> non-functional.
> 
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.3) Gecko/20041022
Firefox/1.0 (MOOX M2)

This is also intermittent for me, but I experienced a similar problem with
multiple (3 in this case) tabs open. Focus was on the 3rd tab (last opened).
Highlighted text to copy but then right click showed a standard page context
menu rather than an edit (copy/paste) context menu. Selected "Edit>Select All"
from toolbar menu. Nothing was selected on the focussed tab (tab #3) however
when I moved the focus to the first opened tab (#1), all the text on *that* page
had been highlighted. 

The behaviour of this bug changed in RC1 (Windows XP Sp1)

New behaviour
a) bug occurs and clipboard cleared
b) subsequent control C and the previous contents of the clipboard are pushed
back into the clipboard, then the new (hilited) portion is pushed into the clipboard

Old behaviour
a) bug occurs and clipboard cleared
b) subsequent control C and the previous contents of the clipboard are *lost*,
then the new (hilited) portion is pushed into the clipboard

You can see this behaviour using Mike Lin's "Clipomatic" which maintains a
history of the clipboard.
I can duplicate this bug *ALWAYS*...EVERY single time.....Windows XP Pro
SP1....Firefox 1.0(the new one just relased)...but this has happened on .09 as
well.This also *ALWAYS* occurs in Thunderbird .09.If I copy..it wipes the
clipboard...as opposed to copying to it.

Steps to duplicate...:

1.Copy ANYTHING in Firefox...url,text from page,it really doesn't matter
2.Try to paste it OUTSIDE of firefox(ie: into an msn chat,or text file)
3.You should recieve no output


This doesn't occur if I try to paste from Firefox to Firefox(ie: text from page
to location bar) *checks* ...tho it definately occurs Firefox to Thunderbird as
well.

Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0

AMD Athlon XP 2000+,384MB DDR 266 RAM

Any suggestions on how to further assist in determining the exact cause of the bug?
(In reply to comment #60)
> I can duplicate this bug *ALWAYS*...EVERY single time.....Windows XP Pro
> SP1....Firefox 1.0(the new one just relased)...but this has happened on .09 as
> well.This also *ALWAYS* occurs in Thunderbird .09.If I copy..it wipes the
> clipboard...as opposed to copying to it.
> 
> Steps to duplicate...:
> 
> 1.Copy ANYTHING in Firefox...url,text from page,it really doesn't matter
> 2.Try to paste it OUTSIDE of firefox(ie: into an msn chat,or text file)
> 3.You should recieve no output
> 
> 
> This doesn't occur if I try to paste from Firefox to Firefox(ie: text from page
> to location bar) *checks* ...tho it definately occurs Firefox to Thunderbird as
> well.
> 
> Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
> 
> AMD Athlon XP 2000+,384MB DDR 266 RAM
> 
> Any suggestions on how to further assist in determining the exact cause of the
bug?


I find this only happend when you ctrl+c to copy, RMB and 'copy' or 'cut' works
fine. Dunno how this helps, though...
Neither works...I've tried both :P
This bug always happen if keyboard layout isn't english. My steps to reproduce:

1) Switch to non-english keyboard layout
2) Select url from address bar
3) Ctrl-C it
4) Try to paste it to notepad

I think this is the cause of such unreproducible bug behaviour.
But this isn't an only cause.

This bug occures with english keyboard layout but less frequently
But this isn't an only cause.

This bug occures with english keyboard layout but less frequently
I see this happen pretty often, but I have noticed an additional focus problem
that occurs simultaneously.

Occassionally when I am typing into a text box, if I use a slash or an
apostrophe, the find menu will pop up and my text will start showing up in that
menu rather than the text box.

Most of the time, when I type into a text box, I can use those characters
without the find menu appearing.
comment #66 describes bug 264876
(In reply to comment #60)
> I can duplicate this bug *ALWAYS*...EVERY single time.....Windows XP Pro
> SP1....Firefox 1.0(the new one just relased)...but this has happened on .09 as
> well.This also *ALWAYS* occurs in Thunderbird .09.If I copy..it wipes the
> clipboard...as opposed to copying to it.
> 
> Steps to duplicate...:
> 
> 1.Copy ANYTHING in Firefox...url,text from page,it really doesn't matter
> 2.Try to paste it OUTSIDE of firefox(ie: into an msn chat,or text file)
> 3.You should recieve no output
> 
> 
> This doesn't occur if I try to paste from Firefox to Firefox(ie: text from page
> to location bar) *checks* ...tho it definately occurs Firefox to Thunderbird as
> well.
> 
> Mozilla/5.0 (Windows; U; Win98; en-US; rv:1.7.5) Gecko/20041107 Firefox/1.0
> 
> AMD Athlon XP 2000+,384MB DDR 266 RAM
> 
> Any suggestions on how to further assist in determining the exact cause of the
bug?



I atchually just reinstalled XP...clean install...and reinstalled firefox..now
both methods of copy/paste work(menu and keyboard shortcuts)...whereas before if
I reinstalled they didn't.
Well, my way to reproduce this bug (Firefox 1.0 German, Windows XP SP2, Office 
XP SP3, fresh and clean install) is:
1) Open firefox.
2) Navigate to www.google.de
3) Enter Anything in the search field
4) Press ctrl-a (select all)
5) Press ctrl-x (cut)
6) Press ctrl-v (paste)

Repeat Steps 4) 5) 6) until it wont paste anymore. By the way, if I use shift-
del and schift-ins instead of ctrl-x and ctrl-v there is absolutely no 
difference in behaviour.  Maybe anyone else is able to reproduce it that way?
Confirmed broken on Firefox 1.0 on both OS X and Win 2000. Geez! I couldn't even
paste the version number into this box b/c it was broken. Also, now there's one
more vote for this thing.
Another confirmation, on two different platforms.  Using Firefox 1.0 (release)
on both Windows 2000 and XP and encountering this bug CONSISTENTLY, both at home
and at work.  Basically, copy and paste no longer works for me in regards to
Mozilla Firefox.  I can highlight anywhere I want to in the browser window -
content on the screen, a URL in the address bar, wherever - and I can do either
a Ctrl-C or a Ctrl-X or even use 'Edit -> Copy' in the menu, but the clipboard
never fills.  As a matter of fact, usually the clipboard empties of its previous
content whenever I try to copy something from Firefox, which I find a little
frustrating since it seems "something" is happening.  Of course, 'try' is a good
word for it, and I think my compatriates here at work are tired of hearing me
constantly clicking Ctrl-C over and over trying in vain to copy text into
clipboard - usually I can get text to copy in one out of every 30 attempts to
copy.  It wouldn't be so bad except for the fact that I rely on Firefox for my
job (I'm a web developer) and copying/pasting text from the screen is NECESSARY
for my task.  So necessary, in fact, that I'm almost in a position where I have
to think about an alternative to the Firefox browser such as IE.  :-(  (Which
would be a shame considering how much I love Firefox, and how much I support
what the Mozilla guys are doing.)  You have to understand, I'm in a position
where I normally have to copy something to the clipboard perhaps once every five
minutes on average.  With a faulty, well, barely working copy/paste function in
Firefox, you can imagine how irritated I can become.  It's become so bad that I
second-guess copy/cut in other applications outside of Firefox - even today I
wasn't sure if my highlighted text in Microsoft Word was going to copy after I
clicked Ctrl-C, conditioned to the constant failures I'm getting with Mozilla. 
I've grown so impatient with this problem that I've had to register an account
with the Mozilla.org Bugzilla and add my voice to the masses.  I apologize at
sounding so negative or frustrated, but I'm just trying to iterate just how big
of a problem this is to me since there has been no improvements after several
releases now.  Perhaps I should go back to an earlier version of Firefox?  I
might have to.
Is Blake the right person to investigate this critical focus bug?
Keywords: regression
Assignee: firefox → bryner
I think this bug is related to bug 264876. They both deal with a focus break.
For example to solve the copy & paste problem, you can try to switch between
windows and then you will be able to copy & paste. To solve the Find Toolbar
popup problem reported in bug 264876 you can also try to switch from one window
to another. Switching between windows allow Firefox to get the focus back to the
active UI elements : TEXTAREA (users is writing), address bar (can't copy URL),
selected text (can't copy selected text)...
Following the steps in comment #35 don't do it for me (FF 1.0, XPSP2), but it
happens inevitably sooner or later.

I open and close lots of tabs (one of the main reasons I'm using FF), and
restarting the browser seems to fix the problem temporarily.

I was just starting to become an evangalist, but this bug is a show stopper IMO.
The whole advantage of having multiple tabs to shift text and URLs between
dissapears when you can't copy. Looks like it might be back to IE (shudder)as my
primary browser for a while yet.
I've tentatively found a cause for this bug, under XP Pro SP2 and using Firefox
V1.0.   

After removing V5.0 Intellipoint drivers for my Microsoft Optical trackball, and
rebooting, I tested Firefox and have copied into the clipboard various pieces of
text from different web pages correctly, 50 consecutive times.  The bug used to
be reproducible on my PC about every 5th copy.

If anyone can verify that the Intellipoint drivers caused the problem, here is
more info.  I started with V4.xx Intellipoint drivers which exhibited the bug
and some time later upgraded to V5.0 (who would believe that I suspected the
mouse driver at that time?) but they didn't resolve the bug.  I downloaded
Intellipoint drivers V5.2 today and uninstalled V5.0. I am too chicken to
install V5.2 now that I have a working Firefox and don't have to check the
clipboard every &^$#^%$ time I want to use it. :)



I don't know much about bugzilla so will post this into both of the entries for
this bug, including the duplicate.
I *do* have a microsoft mouse on both computers that I've seen this on....
However, I don't have the Intellipoint drivers installed *unlesss* windows does
it automajikaly.... anybody know if this is the case, and how to remove them to
test?
i have a logitech MX510 mouse (latest drivers) in a Windows XP SP1, Firefox 1.0
and i have the same problem.

My keyboard is a Portuguese one.
If Micro$oft Intellipoint is the cause (I have 4.1 here on Win 2000 and haven't
seen the bug lately), that wouldn't explain the the OS X side of this bug.
There, I've seen the issue but I use a Logitech keyboard, mouse and trackball
w/out any of Logitech's funky drivers. :|
Blocks: majorbugs
I'm also seeing this behaviour combined with the inability to move the cursor
using the cursor keys in a textbox. Using the mouse to move the cursor by
clicking in the textbox does work.

In the most recent case, attempting to paste in a textbox in a page resulted in
the pasted text appearing in the URL line of the browser instead of the textbox
where the cursor was.
*** Bug 273367 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8b) Gecko/20050117 Firefox/1.0+

i tried to reproduce it now once for all (i hope):
01. open Firefox (maybe with -safe-mode)
02. open https://bugzilla.mozilla.org/show_bug.cgi?id=220900
03. mark & copy some word (like hardware, product, version etc.)
04a. try to paste in additional comments field -> pasteable
04b. alternativle - before proceeding - once click with the mouse at the white
background
05. now write some text in comments box (like 'test123')
06. mark it & right click it und copy it -> pasting disabled

workaround:
once click in the textbox and repeat steps 05. & 06. -> pasting is possible.

this bug indeed seems being like a focusing issue. it has its problems not only
with text/formboxes but also with the URL bar which is _very_ annoying makes FF
sometimes _unuseable_.
for me it should have been a 1.0 blocker, and _definately has to be_ one for 1.1
cause of its annoyance.

(In reply to comment #80)
> *** Bug 273367 has been marked as a duplicate of this bug. ***
I'll look at this tommorow.
Assignee: bryner → aaronleventhal
Blocks: focusnav

*** This bug has been marked as a duplicate of 279496 ***
Status: NEW → RESOLVED
Closed: 20 years ago
Resolution: --- → DUPLICATE
Does that patch solve this bug?  This wasn't limited to input or textarea
elements...
I agree. This was a much more general bug than the "input field"-centric bug
that it's been resolved as a duplicate of.

If that patch fixes this, then great, but otherwise, this should definitely be
reopened soon.
Dup'ing "forward" toward a bug with a more narrow summary set of my alarms too.
 Aaron, what's the deal?

/be
Reopening until we are clear that this is the same problem
Status: RESOLVED → REOPENED
Resolution: DUPLICATE → ---
I for one (peon that I am) am certain it's not.  Just the same, I'm attempting
to get a build so I can apply the patch for testing.

-kz
i've just confirmed the patch does not fix this bug.
(In reply to comment #89)
> i've just confirmed the patch does not fix this bug.

So i guess you have valid steps to reproduce this bug...
The steps I outlined in #41 have always created the bug for me.  The still do on
the version I just pulled from cvs (unless I messed my build up some way, which
seems not likely)
Unfortunately I just repeated the steps in #41 about 11 times exactly as
described with build 20050111 (win32)... never manifested itself unfortunately.
that has been, sadly, my history with this bug.  which is why i've grabbed and
built the source code and am preparing to debug it myself.  As I am coming cold
into the code, perhaps somebody could point me in a general direction, but if
not, I'm content to hunt.  I shall, of course, notify you of my progress.
alrighty then.  I'm now running a debug build of firefox, and going through my
steps gives me lots of these:

###!!! ASSERTION: aaa: 'Error', file c:/builds/gpl/mozilla/layout/xul/base/src/n
sMenuPopupFrame.cpp, line 915
###!!! ASSERTION: aaa: 'Error', file c:/builds/gpl/mozilla/layout/xul/base/src/n
sMenuPopupFrame.cpp, line 915
###!!! ASSERTION: aaa: 'Error', file c:/builds/gpl/mozilla/layout/xul/base/src/n
sMenuPopupFrame.cpp, line 915
###!!! ASSERTION: aaa: 'Error', file c:/builds/gpl/mozilla/layout/xul/base/src/n
sMenuPopupFrame.cpp, line 915
###!!! ASSERTION: aaa: 'Error', file c:/builds/gpl/mozilla/layout/xul/base/src/n
sMenuPopupFrame.cpp, line 915

Interestingly enough, the bug itself does not appear.  I rather suspect this is
because the message box that comes up "fixes" whatever focus issues may be going
on (keep in mind that this bug can be worked around by franticly clicking about
and then coming back and re-copying whatever you were trying to copy).  So, how
can i keep the debug build, but cause NS_ASSERTION to not pop up the message? 
If you all don't reply, that's fine; I'll figure it out next time I get a chance
to work on this.

-kz
back again.  Disabling the assertions didn't make this bug come back in my debug
build.
*** Bug 256954 has been marked as a duplicate of this bug. ***
*** Bug 285969 has been marked as a duplicate of this bug. ***
It has been reported to me and it's a major annoyance for some people
Flags: blocking-aviary1.1?
Keywords: conversion
This may have something to do with the MS Office clipboard.  

To reproduce this issue (Windows XP, Office 2000). 
1) Open Outlook, 
2) copy 13 different pieces of text.  (You should get a message saying the
clipboard can only hold 12 items).
3) Open a new Firefox window 
4) Try to copy and then paste.  The paste part doesn't work.  
5) If you then close Outlook (Exit & Logoff), copy & paste will work again. 


More details:
-After step 2, existing Firefox browser windows can still copy & paste.  To get
it to break, you must either open a new browser window or load a new web page.
-You don't need to close MS Office to fix it again.  You can clear the Office
Clipboard (enable the clipboard toolbar to get to this function) and then copy
something else in Office.  (Simply clearing the Office clipboard didn't work for
me. Maybe copying something else inside of office resets something)
Assignee: aaronleventhal → bryner
Blocks: deera11y
Status: REOPENED → NEW
This bug effects both Firefox and Seamonkey. Changing product accordingly.

The workaround in comment #29 works well for me. When this bug occurs, I just
open a new window, do some copy/paste in there and things are back to normal.

Prog.
Component: General → Editor
Flags: blocking0.9-
Product: Firefox → Core
Whiteboard: Steps to reproduce in comment #35 (intermittent) → Workaround in comment #29 | Steps to reproduce in comment #35 (intermittent)
Version: unspecified → Trunk
I'm on OS X -- Panther now -- and it STILL happens from time to time. M$ office
is not running when it happens. So it may be because of the way that Firefox
utilizes the system clipboard, but I doubt that M$ Office has anything to do
with it. The ultimate test, though, would be to find a machine (Windows or Mac)
without Office and see if the bug appears. 
A couple related points.
The Remote Desktop Protocol (RDP) client on Windows keeps the local and remote
clipboards in sync.  Something about this interaction causes Firefox/Thunderbird
clipboard Copy operations to fail[1] regularly, though not 100% of the time. 
Doing a clipboard copy on the remote host fixes it so Firefox/Thunderbird work
again.

MS Office 2003 stores clipboard history and has the same interaction problem
with RDP client (can't copy/paste).

I belive this clipboard interaction problem is separate from the focus related
issue also talked about in this bug.

[1]
Select text in the Firefox address bar, main browser window, or Thunderbird
compose window; in the menu choose Edit | Copy, then choose Edit again and see
the Paste selection is still greyed out -- there's nothing in the clipboard.
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.7.7) Gecko/20050414
Firefox/1.0.3 -- Panther 10.3.9 -- WORKAROUND.

Once this happens, if you go to another application (say Mail) and copy
something there, then paste it in the search bar, suddenly you can type in the
address bar and the search bar again, and paste works again.
No longer blocks: majorbugs
I'm back.  And, thanks to slashdot, I figured this out, at least for me.  It's
*slow*, not failing to work.  If, when this problem crops up, I wait for two
seconds after issuing the copy command before switching to another app (or, i
think, switching tabs in ff) it starts working again.  So I have a workaround
now, I'll shut up and go away.

I'm just too fast for my computer.

-kz
It happens too much and this is so annoyning if you have a long url and want to
copy it AND IT DOESN'T work! I get very angry because you have NO CHANCE to get
this *** long URL to your mail / other browser / editor etc. 

I switched to Opera now, because I don't want to kill my computer the next time
when this happens...
This is driving me absolutely nuts and I cannot pick when it works or doesn't work! 

Strangely my current work PC has exhibited this problem with both Mozilla and
all of the Firefox releases even across OS reinstalls, yet I've never
experienced the problem on any other PCs.

This is so maddening, that I'm literally wanting to use IE which is practically
unthinkable otherwise.

Copy and paste works fine - then spontaneously stops working. Pretty much I can
guarantee that this problem will strike every day. I can only get it to work
again by resizing the browser a few times, toggling tabs about until sometimes
it just decides to work. Other times I cannot get it to come right. When you
have as many tabs open as I do (say a dozen plus) I'm usually reluctant to stop
and start my browser. I've tried many of the "fixes" outlined here to no avail.
Commenters in bug 299514 (probably dupe) say, that since end of June is this bug
 more frequent.
Flags: blocking1.8b4?
Flags: blocking-aviary1.1?
*** Bug 300643 has been marked as a duplicate of this bug. ***
(In reply to comment #102)
> A couple related points.
> The Remote Desktop Protocol (RDP) client on Windows keeps the local and remote

Thanks for the hint. Remote Desktop Connection is definitely the source of this
problem on my computer. If I close down the remote connection the copy-n-paste
starts to work immediately.

Quick steps to reproduce:

1. righ klick in navigation toolbar (selects all)
2. c (copy)
3. repeat - the next time around 'paste' will not be available.

If a repeate this X times 'paste' will be available ~X/5 times.

Work around: start the clipboard viewer! (clipbrd.exe)
not going block on this.
Flags: blocking1.8b4? → blocking1.8b4-
(In reply to comment #109)
> Thanks for the hint. Remote Desktop Connection is definitely the source of this
> problem on my computer. If I close down the remote connection the copy-n-paste
> starts to work immediately.

the problem has nothing ... really nothing to do with remote desktop. i had this
problem on win2k too what has no build-in remote desktop support (see comment #8).

> Quick steps to reproduce:
> 
> 1. righ klick in navigation toolbar (selects all)
> 2. c (copy)
> 3. repeat - the next time around 'paste' will not be available.
> 
> If a repeate this X times 'paste' will be available ~X/5 times.

yep, these steps for reproducing are still valid

> Work around: start the clipboard viewer! (clipbrd.exe)

verified ! this workaround seems to work.

ps. it's a shame this bug not being fixed and being carried from ff 0.6 past ff
1.1 over to nowhere ...
Verified that clipboard viewer solves the problem for me. 

Is anyone working on fixing this? I would consider raising the priority on this
bug, as it is a showstopper for me, and I imagine for many other IE users like
me, who are trying hard to switch to Mozilla. I go through about 100-200 browsed
pages per day, and I'd say that currently about half of that is in Mozilla...and
typically I hit this bug around the 20th page view or so in Mozilla. Once I hit
the problem (before trying this clipboard viewer fix) that was it - the browser
was essentially dead for me, as I couldn't even copy a link and email it to
someone. From this point forward, the bug persists on all existing tabs and
windows loaded, as well as new tabs and new windows opened.

Opening clipboard viewer every time is more trouble than it's worth - I will
find myself gravitating back towards IE until this is resolved.

Thanks.


re #112

Yes. Yes.

These intermittent bugs seem to hang around forever.  (This one is over a year
and a half old).  And Firefox's everything-in-one-process architecture means
that a fatal problem displaying one web page ruins Firefox for every other page
that's also open, which amplifies the downside of the bug.
This bug is really a huge problem.. Common theme -- more than one instance of
Firefox running, multiple tabs, etc.. Basically it tends to strike when you
really have a lot of work already open and need to start exchanging data from FF
to other things.  I cant say how many times Ive had to use the IEView extension
to open up pages in IE when FF wouldnt allow me to cut/copy to the clipboard.
Alright, I've been seeing this bug a bit more randomly (and more often) in the
nightlies as of late, so I've come to point out anything I've noticed.

* Some specific sites (such as Slashdot), when loaded, don't ever seem to have
the problem.
* Loading a site from a folder within the bookmarks toolbar seems to always
break the focus-dependent tasks.
* These focus-dependent tasks (such as ' and / for searching the page, or
Backspace to go back a page, Home/End and Pg Up/Pg Down for jumping in the page,
the arrows for shifting the page) will not work when you are not focused inside
a form, but only the ' and / will do anything when focused.
* Copy/Paste does indeed break still, copied text is still in clipboard, other
times it is impossible to copy text.
* No real workaround; once the bug triggers, most pages will be b0rxed.  This
does NOT, however, affect extensions' text boxes, so the bug seems to be within
the HTML portions of Gecko and not so much in the XUL/XBL/XML/etc. portions.
* I don't know about this one, but I think that once the focus-tasks break, when
viewing the source of a page (in a new window), you can use a cursor to navigate
around the source page, even when that option is disabled.
(In reply to comment #115)
> Alright, I've been seeing this bug a bit more randomly (and more often) in the
> nightlies as of late, so I've come to point out anything I've noticed.
> 
> * Some specific sites (such as Slashdot), when loaded, don't ever seem to have
> the problem.
> * Loading a site from a folder within the bookmarks toolbar seems to always
> break the focus-dependent tasks.
> * These focus-dependent tasks (such as ' and / for searching the page, or
> Backspace to go back a page, Home/End and Pg Up/Pg Down for jumping in the page,
> the arrows for shifting the page) will not work when you are not focused inside
> a form, but only the ' and / will do anything when focused.
> * Copy/Paste does indeed break still, copied text is still in clipboard, other
> times it is impossible to copy text.
> * No real workaround; once the bug triggers, most pages will be b0rxed.  This
> does NOT, however, affect extensions' text boxes, so the bug seems to be within
> the HTML portions of Gecko and not so much in the XUL/XBL/XML/etc. portions.
> * I don't know about this one, but I think that once the focus-tasks break, when
> viewing the source of a page (in a new window), you can use a cursor to navigate
> around the source page, even when that option is disabled.

Edit:
* This may be a problem with <textarea>s that contain any sort of text inside it
at renderring time.  If the form's textarea does not basically go
<textarea></textarea>, the focus-tasks might be breaking due to something about
that.  I'm thinking this because Bugzilla's forms haven't broken for me yet, but
the ones that have usually have something like a signature or some whitespace
and whatnot within the textarea.

Also, can anyone confirm if this problem exists in application/xhtml+xml pages?
 If it does, can you trigger the problem via an application/xhtml+xml page?  I
can make a few testcases regarding this, but I'd like to see if any of you think
this might be worth looking into.
Blocks: 254592
Depends on: 258285
I used to have WXP SP1 and SP2 as workstation and W2000 SP4 as the server where
MSTSC connects were made and this bug occurred still somewhat randomly. Now when
workstation is WXP SP2 and server is W2003 SP1 then whenever there is at least
one active MSTSC session then I'd say 90% of all copy actions in FF1.0.6 and TB
1.0.6 result this bug.

Workarounds (delete local clipboard or waiting some seconds before retry) still
work, but the bug is often so annoying that if more copying work has to be done
then I switch to Opera :)
*** Bug 302720 has been marked as a duplicate of this bug. ***
The other posters only mention clipboard problems in Firefox.

Usually i have two instances of Firefox running. One with three tabs:
OpenGroupware, Wiki and our Timerecording. The second instance is just for
surfing the web. Additionally Thunderbird, Remote Desktop and FileMaker 5 is
running.

When i encounter the bug after a while, the whole Windows clipboard is
dysfunctional.

That means: it is not possible to transfer data between any applications via
clipboard at all.
Flags: blocking-aviary2.0?
Was this fixed by the checkin for bug 258285?
(In reply to comment #120)
> Was this fixed by the checkin for bug 258285?
It seems very likely as haven't experienced it since then. Unless no one reports
seeing this bug in recent builds I suggest RESOLVED FIXED.


(In reply to comment #120)

no. i have to admit that the amount of this bug to happen shrinked for some
time. but i guess it regressed then. got no window for this tough.

(In reply to comment #121)

yes, this bug still affects me. don't even dare to set it fixed ;p
 
I believe the remaining issues occur when Firefox is relaunched a 2nd time via a
desktop icon or some other OS method.
(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1)
Gecko/20021130
> Build Identifier: Firebird 0.6.1
> 
> On about 1 out of 10 pages, the Copy command on the edit menu is grayed out, and
> the kbd shortcut doesn't work either.  Sorry, can't reproduce it, but it happens
> often.
> 
> Context: Many Firebird windws open (often a couple of dozen)
> 
> When this happens, the mouse wheel doesn't work either. (to be reported next). 
> Strictly speaking, I can't be sure that when one happns, the other does too
> (because I don't test every page I see) but when one becomes apparent, I test
> the other also.
> 
> Reproducible: Couldn't Reproduce
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
> See above discussion of irreproducibility.
> Actual Results:  
> Firebird doesn't put the highlighted text in the Windows paste buffer.
> 
> Expected Results:  
> Firebird should put the highlighted text in the Windows paste buffer.

(In reply to comment #0)
> User-Agent:       Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.2.1)
Gecko/20021130
> Build Identifier: Firebird 0.6.1
> 
> On about 1 out of 10 pages, the Copy command on the edit menu is grayed out, and
> the kbd shortcut doesn't work either.  Sorry, can't reproduce it, but it happens
> often.
> 
> Context: Many Firebird windws open (often a couple of dozen)
> 
> When this happens, the mouse wheel doesn't work either. (to be reported next). 
> Strictly speaking, I can't be sure that when one happns, the other does too
> (because I don't test every page I see) but when one becomes apparent, I test
> the other also.
> 
> Reproducible: Couldn't Reproduce
> 
> Steps to Reproduce:
> 1.
> 2.
> 3.
> See above discussion of irreproducibility.
> Actual Results:  
> Firebird doesn't put the highlighted text in the Windows paste buffer.
> 
> Expected Results:  
> Firebird should put the highlighted text in the Windows paste buffer.

(In reply to comment #123)
> I believe the remaining issues occur when Firefox is relaunched a 2nd time via a
> desktop icon or some other OS method.
Similar problem in Deer Park Alpha 2. (Mozilla/5.0 (Windows; U; Windows NT 5.1;
en-US; rv:1.8b3) Gecko/20050712 Firefox/1.0+)
(Using XPSP2 all updates, Office 2003 all updates, .NET framework 1.1)
I have had this problem in the SFX forums and blogs. It seems to be combined
with the type to find feature. I'll click in a text box and start typing and the
find bar pops up. (Copy and paste get funny too.) Very rare though. I abuse the
Hibernation feature of XP. The problems start to happen after the 4th or 5th
hibernation. 
(In reply to comment #109)
> Work around: start the clipboard viewer! (clipbrd.exe)

Furthermore, this only helps if `clipbrd` is started after `rdesktop`.
Restarting `rdesktop` means I have to restart `clipbrd`.


These focus-related problems are worse than ever for me with firefox 1.5 beta on
both Mac and Windows.  As usual, the common theme seems to be >1 FF window open.
Now with added REPRODUCABILITY!

Steps to Reproduce:
1. Double-click Firefox desktop shortcut
2. Type wikipedia.org into URL bar
3. Click text field under the globe
4. Type /
5. Focus -> text field
6. Without closing the first window, repeat steps 1-4. Now:

Actual Results:
7. Focus fails to go to text field, Find toolbar appears

Expected Results:
7. Focus should behave in the second window as it did in the first.

Platform details:
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050908 Firefox/1.4

Windows 2000/all updates applied
Ben, that's bug 307375.
This bug is driving me absolutely insane!

As you can imagine, not being able to copy the user-agent from the about window
is making it even more frustrating. 

My experience is similar to those above. If I go out to notepad and copy some
text, it pasts fine. I come back to firefox, I can copy, but not paste. When I
switch back to notepad, I can no longer paste, as my clipboard is empty. 

When it does work, copying and pasting is now adding a space  at the front of
pasted text as well.

Here's another oddity. When I copy from this page itself above (for example,
"Show dependency tree"), it works, but when I copy text from within this field
window, I can't paste. Sometimes. 

Mozilla/5.0 (Windows;U;Windows NT 5.1; en-US; rv:1.7.10) Gecko/20050716
Firefox/1.0.6

Right now I have one firefox window and 11 tabs open.
Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.8b4) Gecko/20050915
Firefox/1.4 ID:2005091504

I haven't seen this in a long time and I use copy/past umpty times per day.

You can either live with it untill FF1.5 comes out or try FF 1.5 beta 1
*** Bug 308909 has been marked as a duplicate of this bug. ***
Beta 1 has serious focusing problems. See bug 308882

(In reply to comment #131)
> You can either live with it untill FF1.5 comes out or try FF 1.5 beta 1


Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.9a1) Gecko/20050917
Firefox/1.6a1 ID:2005091723

I have very frequently problems in trunk and branch. What goes wrong in nearly
100% of the cases is pasting an url in the Adblock Preferences window.

Testcase:
- Make a new profile and install Adblock Plus in it:
http://bene.sitesled.com/adblock.htm
- Copy a link and open Tools > Adblock Plus > Preferences.
- Paste the url into the input field.
- It will not succeed, at least not here and on this computer.
- Then paste the url (still present in the clipbord) into Notepad.
- Select the url, rightclick > Copy.
- Then paste the url into the Adblock input field.
- This will succeed.

This same happens very often with other inputfields, also when there is no
Adblock involved.  
*** Bug 309478 has been marked as a duplicate of this bug. ***
*** Bug 309762 has been marked as a duplicate of this bug. ***
Mozilla/5.0 (Macintosh; U; PPC Mac OS X Mach-O; en-US; rv:1.9a1) Gecko/20050923
Firefox/1.6a1 ID:2005092306

I don't know it is the bug I have encountered or a new one.  The problem I have
encountered did not surface until the updates applied on around Sep 20 of
DeerPark alpha 2.

I can't copy in the content of the the webpage with shortcut key Cmd-C nor from
the pull down menu since "Copy" is dimmed.  However, right-click->copy works.

The text inside textarea and input tag are unaffected nor is the location bar.

On the other hand, the paste always works.  The content of clipboard is never
cleared.  It just paste the content of the clipboard before the last copy made
in DeerPark which indicates the copy isn't working only.
*** Bug 310423 has been marked as a duplicate of this bug. ***
Since posting this bug, I've since discovered that the problem only crops-up
when more than one tabbed window is open.  With only one tab open, I've never
had any troble with cutting, copying, and pasting. 
>Since posting this bug, I've since discovered that the problem only crops-up
>when more than one tabbed window is open.  With only one tab open, I've never
>had any troble with cutting, copying, and pasting. 

Well, then.  I guess I'll just switch to IE if it comes to that... :P

On a more serious note, I switched to deer park a few weeks back, right after
comment 120.  At that point it seemed to get a bit better for a few days, but I
wasn't using my PC quite as heavily as sometimes.  More recently, the problem
has again surfaced, and it seems as bad as before.  I do launch many of my links
from the start->run command in windows (copy them from other places), so comment
#123 would apply to me.  I also run remote desktop a lot, so that part would
apply to me as well.

I am able to see this issue on both windows XP (two different machines) and
windows 2000 (my laptop).  If I can be of ANY assistance in the debugging of
this PLEASE let me know.  I'ld LOVE to help as this is the MOST ANNOYING BUG EVER!!!

thanks,
-kz
I suggest that comment #109 is noted as a workaround in "Status Whiteboard".
(I'm not allowed to do so.)
Suggested workarounds thus far:

1. Open the current page in a new window (I usually just open any page in a new
window and check copy/paste there).
-or-
2. Start -> Run -> clipbrd.exe (Clipboard Viewer)

Prog.
Whiteboard: Workaround in comment #29 | Steps to reproduce in comment #35 (intermittent) → Workarounds in comment #142 | Steps to reproduce in comment #35 (intermittent)
This is supposed to be fixed in (very) recent builds.
Flags: blocking-aviary2.0?
Just happened to me with Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US;
rv:1.9a1) Gecko/20051007 Firefox/1.6a1 ID:2005100706
Copy and Paste - Bug in Firefox

(Different versions, different OS)

https://bugzilla.mozilla.org/show_bug.cgi?id=220900

Workaround not working for copy & paste - bug (In reply to comment #142)

*To run clipbrd.exe (Clipboard Viewer) does not solve the copy and paste
problem, neither does opening in a new window.
*Only workaround for me is to copy from one tab, paste in note/text/any-pad,
swich to the new pad, copy from anypad and paste it. This only works if I swich
windows before the second copy and paste, otherwise the clipboard is blank again
*argh*. Awful if you work with tabs, wikis or anything.
*Other workaround is to work with one instance of firefox and do all copy and
paste operations from or 2 opera...


Situation:

Copy and paste between different tabs or windows does not work at all (100%).
This problem does not affect other applications, just firefox. It seems that the
clipboard is deleted (for security reasons?!) when swiching from one tab/window
to another, but not when working with external programs...

System:

WinXP_Pro_SP1, Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12)
Gecko/20050915 Firefox/1.0.7 (happened in the earlier version I had installed
2), Extensions: DOM Inspector, Wikipedia, Greasemonkey, CopyPlainText (tried is
as a solution for the copy and paste problem), RoboForm;

Unsuccessful tries:

1.Reinstalling after cleaning all data from previous installs
2.New User Profile
3.Open Clipboard
4.CopyPlainText (tried is as a solution for the copy and paste problem)
5.Work only with Firefox Windows, not with tabs
6.Upgrade to Firefox 1.0.7
7.Playing around with security settings

----

Suggested workarounds thus far (comment #142):
 
1. Open the current page in a new window (I usually just open any page in a new
window and check copy/paste there).

2. Start -> Run -> clipbrd.exe (Clipboard Viewer) 

3.Copy from one tab, paste in note/text/any-pad, swich to the new pad, copy from
anypad and paste it. This only works if I swich windows before the second copy
and paste, otherwise the clipboard is blank again 

4.Work with one instance of firefox and do all copy and paste operations from or
2 opera...
Blocks: 311883
I found some clipboard-programs one can use while this bug is still present:

- Ditto (http://ditto-cp.sourceforge.net/)
- You can add other programs here to keep people using the fox : )
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915
Firefox/1.0.7

very simple things can't work already:
1) type something in the url
2) select them, copy them
3) paste on the google (or whatever) search tab on the right
won't paste

there's a lot more other way copy and paste isn't working. this is causing me
switching back to IE.
*** Bug 315721 has been marked as a duplicate of this bug. ***
*** Bug 314045 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary2?
Flags: blocking1.9a1?
*** Bug 308379 has been marked as a duplicate of this bug. ***
Flags: blocking-aviary2? → blocking1.8.1?
I don't know if this is of importance. I noticed the bug appears more frequently on machines with hyper threading enabled ("multi processer" in the view of the OS).

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7.12) Gecko/20050915 Firefox/1.0.7

This is one of the most annoying bugs Firefox ever had. Please fix it.
I just tested all the steps-to-reproduce provided along this bug - both in Seamonkey and in Firefox. Nothings seems to cause this behavior. Now, I do encounter this bug every now and then, but without a reliable method to reproduce it, it's practically impossible to fix.

Prog.
Whiteboard: Workarounds in comment #142 | Steps to reproduce in comment #35 (intermittent) → Workarounds in comment #142 | Steps to reproduce needed
For me it is extremely easy to reproduce the bug:
- under WinXP open at least one mstsc session (remote desktop session)
- allow time for screensaver to launch at that mstsc session
- open Firefox, Thunderbird, Seamonkey or Mozilla Suite and try to copy from its window
- clipboard will remain empty, nothing to paste
- close the terminal session and copying works fine again

As I usually have 3-4 mstsc sessions open then the bug is almost 100% guaranteed.

There are two workaronds:
- closing mstsc sessions
- use ctrl+mouse drag to copy (it seems to work)
For me, this was 100% reproducible every sesssion I used the middle click. After the middle botton (scroll botton) on this mouse stopped working, the bug ceased to happen.

*** Bug 323568 has been marked as a duplicate of this bug. ***
This bug has plauged me across 2 machines, clean + full reinstalls of FireFox, and a fresh OS + fresh firefox install. It has made work nearly impossible (i work in wikis all day, copying and pasting).

Today I finally stumbled upon a workaround in this thread which seems to have completely cured the problem. 

Closing mstsc (remote desktop client) enables all the copying, pasting, clicking, multi-windowing and multi-tabbing, etc that I could ever want to do. 

Is it possible that everyone experiencing this was either hitting the "12 items in office clipboard" or "remote desktop client clipboard futzing" bugs? Many of us are sysadmins, and these are very common tools.


13 months and a resolution doesn't seem near.
is focus a red herring, since this became a regression?
is Bug 292395 comment 9 related?
Whiteboard: Workarounds in comment #142 | Steps to reproduce needed → Workarounds see comment #145 | Steps to reproduce needed
I'm seeing this on Win2kSP4 with Seamonkey 1.0b. I also use the remote desktop client (RDC) to connect via VPN to XP machines at my office. (Note that the statement in comment #111 is slightly incorrect. While Win2k lacks a server for remote desktop, a client is available.)

I'm only seeing the address bar symptom: I open multiple tabs, and find myself unable to copy URL's from an address bar. Pasting continues to work.

I've found a pretty reliable workaround: If I copy text in another app, such as Mulberry (IMAP client) or Epsilon (Emacs editor clone), I can once again copy URL's from the Seamonkey address bar. Having just found this bugzilla entry, I haven't yet tested the other workarounds (shutting down RDC or starting clipbrd.exe).

Bug 206764 may be related.
I can second that RDP client and/or Office 2003 have something to do with this bug. I always have Outlook 2003 open and most time at least one RDP session.
Like this, it is really easy to reproduce:
Firefox 1.0.7 (english), WinXP SP2 (french), Office 2003 pro (french).
1) Start Excel 2003, open an RDP session and open Firefox
2) Do some copy and paste in Forms and the address bar of Firefox or between Excel and Firefox or between RDP client and Firefox. This includes - of course - several task changes between the three apps.
3) copy/paste stops working
I disabled the fancy Office 2003 Clipboard, but that doesn't change anything.

The workaround posted on comment #143 doesn't work if Office 2003 / RDP clipboard is used. clipbrd.exe crashes and blocks the clipboard. Now the clipboard doesn't work at all. --> worse!

So, it MAY be related with a big M$ bug.

Greetings
Rufer
(heck I couldn't copy the Firefox Version string when posting this!!!)
I have a bit more info along these same lines.  My coworker came to me the other day and was complaining about this very bug; I showed him this bug report and he confirmed that closing the terminal services client will allow him to copy.  He also discovered that just *minimizing* the RDP client has the same effect - he's then able to copy with no trouble.

Another trick that you all can try is when closing the terminal services client see if you need to recopy.  What we have observed is that you copy from firefox, attempt to paste in another application, the paste fails (is blank), you close terminal services client, and paste right away - no need to recopy.

Finally, I had installed a clipboard monitor called 'ditto' (http://ditto-cp.sourceforge.net/).  Amusingly with this installed I was able to cause a similar problem to occur in other applications - most notably microsoft visual studio 6.  While not as consistent, it did occur...

So then, my conclusions are as follows:
1.  It's not a focus issue at all
2.  There's some weird timing issue associated with copy/paste activity when a clipboard monitor is running (it's worth noting that both terminal services client and office 2003 would require a clipboard monitor to do what they do with  the clipboard - office for it's list of old clipboards and mstsc for it's syncronization of clipboards from client<->server)
3.  It's not going to be easy to fix.  In fact, it's going to be nearly impossible....
Must be synchronization/race problem. My CPU is hyperthreaded, if I set firefox.exe affinity to single CPU, the problem disappears.
(In reply to comment #161)
> Must be synchronization/race problem. My CPU is hyperthreaded, if I set
> firefox.exe affinity to single CPU, the problem disappears.
> 

Anyone else? If so, that should be added to status whiteboard comments/workarounds.
Yep, dual Xeon so 4 logical CPU's on my office XP box. But I also see it on a single P4 running Win2k at home. The common denominator for me seems to be using the remote access client.
I've been seeing this bug consistently every day on my work machine, and it's driving me nuts.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.0.1) Gecko/20060111 Firefox/1.5.0.1

I, like most, have no reliable steps to reproduce the issue. I can, however, give some information as to the bizarre events that happen in conjunction with the clipboard not wanting to work. Most of the people commenting in this bug are aware that "copy" in the "edit" menu will suddenly stop being available. CTRL+C no longer does anything. Highlighting text and right-clicking shows a completely inappropriate context menu (one without "copy" even listed). 

In my experience, I've found that when this problem occurs, other things go along with it. The arrow keys stop working in the browser, and either / or ' will bring up the find toolbar regardless of cursor position. In addition, if text already happens to be on the clipboard when this happens, pasting will occasionally paste the clipboard text into the address bar. 

I'm experiencing the same sentiments as David in comment #106 in that this problem is such a severe hinderence to my work that I almost have to use Internet Explorer instead. The only way I've found to fix the problem is to restart Firefox, only to have it reappear anywhere from 5 to 20 minutes later. 
(In reply to comment #162)
> (In reply to comment #161)
> > Must be synchronization/race problem. My CPU is hyperthreaded, if I set
> > firefox.exe affinity to single CPU, the problem disappears.
> 
> Anyone else? If so, that should be added to status whiteboard
> comments/workarounds.

Confirmed, with some qualifications: the problem disappears here if and only if
I set the affinity for *both* firefox (1.5.0.1 here) and mstc (rdesktop) to the
*same* cpu. (All other combinations failed.)
I'm not entirely convinced it's an rdesktop-related issue since I'm not using rdesktop on my system. The service for receiving it isn't even started.
(In reply to comment #166)
> I'm not entirely convinced it's an rdesktop-related issue since I'm not using
> rdesktop on my system. The service for receiving it isn't even started.
> 

We are talking about the client, not the service.
Sounds like a focus issue. A simple test would be to bring up the about screen (Help...About) and then close it. Does copying/pasting work again? I know that that workaround has worked for other focus issues in the past.
> We are talking about the client, not the service.

I'm aware of that. I'm making the point that I'm not using either the client OR the service.  


(In reply to comment #169)
> > We are talking about the client, not the service.
> 
> I'm aware of that. I'm making the point that I'm not using either the client OR
> the service.  
> 

ah, I am sorry, I misunderstood.
It is most definitely a focus issue since, as I mentioned, when this issue occurs you'll end up pasting data into the address bar regardless of cursor position. In addition, I tried Ryan's fix in comment #168, and it solves the problem.
I have found that when this problem happens, if I click in the addresss bar and then click back on the page and reselect the text I was trying to copy, then it works.  I will try the About->Help to see if that fixes it also.

What is strange is this problem usually happens when I open a Remote Desktop session to another machine. Even if I have that session iconified in the taskbar, I will sometimes have this copy&paste problem in the firefox running on my local desktop.
I can confirm many of the above comments. 
I'm using XP Pro sp2 on an Hyperthread machine and when i open rdesktop towards a remote machine, even if iconified, almost immediatly start appearing the, mentioned problems: copy/paste (both from context menu and ctrl-c/v) not working, page scrolling acting erratically, no more able to scroll pages with mouse wheel, etc. 
Not all the symptoms compare togheter but in a random mix.
As soon as i stop rdesktop all the functions restore back to normal working state without need to restart firefox.
Hope this may help addressing the problem.

Gabriele
This sounds the same as bug 133439, which was just fixed, does this still occur with nightly builds?
Just wanted to add my 2 cents. This appears to occur when I use remote desktop. When I close remote desktop the issue disappears. Your mileage may vary.

Let's hope the previously mentioned bug that was fixed on March 23 will fix this one. This one has been a BIG DEAL and I've tried to leave Firefox because of it, but keep coming back because Opera has some DOM issues.
Flags: blocking1.9a2?
I downloaded Version 1.5.0.2 and this issue has NOT been fixed. 

To recreate it:
1) open a remote desktop connection
2) open FF and navigate to a page with a textarea field
3) try and copy text from within the textarea field to a spot just below the original text in the textarea field.
I'm also still seeing it with SeaMonkey 1.0.1 on Win2kSP4 (freshly installed today) with an RDP session running to my office. As before, I spawned clipbrd.exe and the problem went away.
This sure sounds like an OS bug.

I don't believe it's fixed, and until the bug is marked fixed, there's no point in saying "it's not fixed".

/be
Mathias Rufer #151 in saying: 

> I noticed the bug appears more frequently on machines with hyper threading
> enabled ("multi processer" in the view of the OS).

is right that it is sync issue between processors (or virtual processors as in hyperthreading). In my case setting mstsc processes and seamonkey/mozilla/firefox/thunderbird processes to use the same CPU 0 (e.g. set affinity option on task manager) always fixes this copy-paste trouble.

In fact I have done this in advance for seamonkey/mozilla/firefox/thunderbird by using imagecfg.exe (available in Windows 2000 Server Supplement One Resource Kit).

I can confirm earlier claims that the bug is still in FF 1.5.0.2 and SM 1.0.1.

Interesting hint is that being occasional user of K-Meleon, I have't noticed this bug is not there. As they do not use all components then the circle to search from is somewhat smaller.

And Brendan Eich in #178 has said:

> This sure sounds like an OS bug.

Looks like so, but wild guess it that MS won't fix it - as they would say it occurs only with some Mozilla apps, so it's an app problem.
Assignee: bryner → mats.palmgren
(In reply to comment #179)
> Mathias Rufer #151 in saying: 
> 
> > This sure sounds like an OS bug.
> 
> Looks like so, but wild guess it that MS won't fix it - as they would say it
> occurs only with some Mozilla apps, so it's an app problem.

Some versions of MS Office (with multi-clipboard capability) were also affected by RDP.  I don't know if it's still an issue with latest service packs.

But I think Remote Desktop is a red herring, or at least, in my understanding this bug is talking about two separate issues:

1. Yes, RD causes easy-to-reproduce copy-paste problems (though with FF1.5.x it is somewhat better than before, and often copying a 2nd time will make it work).  

2. However, this bug (and many comments) talk about a separate, focus-related copy-paste issue (where RD is *not* runnning).  This bug is hard to reproduce consitently on different machines.  I personally have not seen it since FF 1.5 (but it is hard to tell because I always have RD running too).

I think it would be helpful to separate the RD issue to a different bug# because mixing the two issues only confuses anyone looking to fix this.

-Nathan
(In reply to comment #180)
> I personally have not seen it since FF 1.5

I can reproduce the focus at will with any 2.0-branch build. WFM without any extensions though, but there is more than one extension that causes it. Adblockplus is one (with adblockplus alone, I can reproduce) but there's more (without adblockplus, but with my other extensions active, I can reproduce too).

> I think it would be helpful to separate the RD issue to a different bug#
> because mixing the two issues only confuses anyone looking to fix this.

Is RD bug actually the focus bug? Can you use arrows to move caret for example (when paste doesn't work), does ' and / in textboxes like this one cause search to pop up?
If you also get the other problems, it's the same issue. If not, then indeed it's separate.
I have not seen this bug in Firefox since I dumped my old PC (WinXPSP1/Firefox 
1.5.01) and went to my new one (WinXPSP2/Firefox 1.5.02, now).  I have, however, 
seen this bug in Thunderbird v1.5 on both machines.  I find that choosing "Paste 
without formatting" from the Edit menu, instead of the prosaic "Paste," always 
works (albeit without formatting).

Does this imply a problem with the OS or does it rather imply it's not the OS at 
all?
*** Bug 337437 has been marked as a duplicate of this bug. ***
Not going to block 1.8.1 for this.
Flags: blocking1.8.1? → blocking1.8.1-
Steps to reproduce, work for me 100%:

1. start a new firefox profile and set your homepage to about:blank. Close firefox.
2. copy some text to clipboard. that's not needed to trigger the bug, just makes following steps easier.
3. Make sure you have a firefox icon on desktop
4. Start FF from desktop, press ctrl-v to check if you can paste to urlbar. If you can't (unlikely) you've reproduced. If you can, minimize this window.
5. start new FF window by double-clicking desktop icon
6. Check if you can paste. If you can, close it and goto 5.

Important: don't make any unnecessary focus changes. It should take below 10 new windows to reproduce. If you've reached about 10 and it still works fine, start over from point 4, I never failed at second try.

Starting new windows from ctrl-N or other methods will not trigger the bug, ever.

Once you can't paste into urlbar, you are free to enjoy the bug until you switch focus to another application. Go ahead, go to google and try to search for ' or /. Arrow keys in urlbar won't work either.

Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1a3) Gecko/20060615 BonEcho/2.0a3
The steps worked fine since at least 1.4.x, perhaps even since FF 0.9.
Please set OS to Windows. This does not happen on Linux. This bug is caused by how MS windows handles mouse(with 3 buttons) and keyboard events. 
Also in windows the clipboard works differently when it comes to where clipboard data is stored. 
On linux, if I copy data from a program then close it, the copied data is lost. On windows it is not lost.
That's why nobody has been able to reproduce this on Linux.
(In reply to Hussam Al-Tayeb, comment #186)
This bug is marked as Hardware=All and OS=All because it also happens on Mac OS X. Bugzilla doesn't offer a way to explicitly exclude Linux when a bug happens on Windows and Mac.

Prog.
re: #187

Yes there is.  It's the "parity" keyword IIRC.
For the record, this bug still appears in Mac OS X (10.4.7) with Firefox 1.5.0.4.
I can confirm that it still exists in 1.5.04 on Windows XP on a single-threaded CPU, and a remote desktop connection makes no difference whatsoever.  This happens on both my work and home computers.

Frankly, this bug is driving up the wall.  This is my #1 most hated bug, and many people I've talked to have experienced this independently of me.  It's elusive and impossible to reproduce every time, and also hard to describe, which is why I think there are so many bugs I suspect are related.  On my Mac I've switched to using Safari exclusively because of it (well--that and the rendering speed issue).

Please... make this a blocking issue for the next major release and squash it once and for all.  :-(
Guys, there really hasn't been any work done on 1.5.0.* to correct this issue, so claiming the bug still exists there is a waste of time.

That said, even if you're still seeing this in the latest branch or trunk builds, your comments are not needed unless you have a reliable way to reproduce this issue.
(In reply to comment #191)
> Guys, there really hasn't been any work done on 1.5.0.* to correct this issue,
> so claiming the bug still exists there is a waste of time.
> 
> That said, even if you're still seeing this in the latest branch or trunk
> builds, your comments are not needed unless you have a reliable way to
> reproduce this issue.

There were comments suggesting that the bug was caused by RDC or a hyperthreaded CPU.  My post was to indicate that this was not the case.
(In reply to comment #191)
> That said, even if you're still seeing this in the latest branch or trunk
> builds, your comments are not needed unless you have a reliable way to
> reproduce this issue.

Steps to reproduce in comment 185, although it would be nice if someone confirmed.
I can't change status whiteboard entry :\
(In reply to comment #193)
> Steps to reproduce in comment 185, although it would be nice if someone
> confirmed.
> I can't change status whiteboard entry :\
> 
comment 185 doesn't present a reliable way to reproduce this bug. It just tells to try the steps again till it breaks.

(In reply to comment #194)
> comment 185 doesn't present a reliable way to reproduce this bug. It just tells
> to try the steps again till it breaks.

But this has always been the only way. This is a standard "reproducable:sometimes" bug.
#185 works for me, every time. let me rephrase that: i encounter this bug *every* single time i run firefox. i can *never* cut-and-past, or use the URL bar, unless i minimize & restore firefox.

what can i do to help you identify why this is the case? im on not my work box were this happens, but when i am on monday what should i send you, my hardware specs?
I do not understand how this is not a blocker bug.
This bug is extremely frustrating, and utterly breaks browser functionality.
Copy and Paste, Arrow Key Movement, Backspace, and other focus related actions are essential to navigating and using the web.

This bug cries out to be fixed, and once this happy day arrives, there should be an immediate and triumphant point release, complete with a slashdot article.

This bug represents a usability crises, and that fact that it was first reported in 2003, and remains unfixed and listed as "NEW" today in 2005, presents a clear counterpoint to the notion of fast, timely, or even fashionably late bug fixes.

This bug needs to be the priority for firefox.

We don't care about tabs having icons, or storing bookmarks in a database.
We want copy, paste, and the various stricken keys on our keyboards to all finally just work.
i dont know if this will help anyone, but these are the windows' System Information specs of my box. the bug is 100% reproducable in this environment. i am happy to provide any other information. -matt
i dont know if this will help anyone, but these are the windows' System Information specs of my box. the bug is 100% reproducable in this environment. i am happy to provide any other information. -matt
Attachment #228683 - Attachment is obsolete: true
I can reproduce this problem on Firefox 1.5.0.6 and Firefox 2.0b1.
Windows 2000 SP4. Ctrl+C, Ctrl+V, Left and Right arrow, Home, End,
etc. (sometimes) doesn't work at address edit line and search edit 
line. The commands from context menu works fine. This happens several 
times a day.

How can I help you to track down this problem?
Flags: blocking1.9a2?
Flags: blocking1.9a1?
Flags: blocking1.9-
Whiteboard: Workarounds see comment #145 | Steps to reproduce needed → [Steps to reproduce in comment 185] Workarounds see comment #145
I got this Problem as well. I tried to make it reproduceable, so here is how I can reproduce this bug:

1. close all Firefox windows.
2. copy a text in the clip port
3. open a new Firefox window
4. open a Link from the current opened window in a new Tab (I used the middle mouse button, but it also worked wit the context menu)
5. open a new Firefox window (I opened it from the quick launch bar; with <ctrl> + <N> it will not produce the bug)
6. try to paste the text in the URL-Field, it won't work!

Hope this will help you, to fix this issue.
(I use Windows XP and Firefox: Mozilla/5.0 (Windows; U; Windows NT 5.1; de; rv:1.8.0.6) Gecko/20060728 Firefox/1.5.0.6)

Additionally to my previous post (#201):

To reproduce the bug you even don't need to open a new link.

You just have to open a new tab in a window (not with keyboard, but every way you can open it with the mouse works fine)

After starting a new instance of FF (e.g. from quick launch) the bug appears.

Hope you can fix it for the next release.
Is it possible, for anyone who's able to reproduce it consistently, to show us any relevant errors in javasript console ? It is quite difficult to do that otherwise. When I encounter this problem, the console is already filled with numerous unrelated errors from various sites.
(In reply to comment #203)
> Is it possible, for anyone who's able to reproduce it consistently, to show us
> any relevant errors in javasript console ?

No relevant errors or warnings show up.
Renominating.  For people who encounter this (an apparently non-trivial number), it's sufficient motifivation to simply stop using Firefox; I came very close.
Flags: blocking1.9- → blocking1.9?
Marking blocking since this is a big deal and steps to repro have shown up in comment 185.  Gavin or Blake have any time to look into this?
Flags: blocking1.8.1- → blocking1.8.1+
I experience this bug frequently, and I discovered that in a window that is currently suffering from this bug if I open and close the javascript console then the problem goes away in that window (it will still come back in (some) new windows).

(In reply to comment #207)
> I experience this bug frequently, and I discovered that in a window that is
> currently suffering from this bug if I open and close the javascript console
> then the problem goes away in that window (it will still come back in (some)
> new windows).
 
Switching focus to any other window - JS console or not - will fix it.
Looks like this isn't going to be ready for FF2.  Mats/Bkap do you have any cycles to look at this for a future release?
Flags: blocking1.8.1+ → blocking1.8.1-
*** Bug 352326 has been marked as a duplicate of this bug. ***
wow there are a lot of different issues crammed into this one! The actual bug this is reporting, though, seems to be the only one left (that the user can't fix themselves).  

RE comment #185 -> is this the same bug as ' and \ trigger find bars in text fields? Bug 320083

I don't recall having copy paste issues, I don't use more than one window, but i did recently have an instance of bon echo not taking focus after an update completed.  Not sure if this is relevant, but from steps to reproduce it sounds like the issue is a new firefox window taking focus when the exe is run. Does it make sense to look at how ctrl+n takes focus and how firefox.exe (etc) absorbs the new process and gives it focus?
oh neat, so I'm having this consistently break on the 3rd window - Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1) Gecko/20060914 BonEcho/2.0

What I'm noticing is happening is only the 3rd window is broken. If I click back and forth in the taskbar I can still copy and paste in the first two windows, but both of those windows still seem to keep some form of focus.  When I click back to the first window, the type I'd selected is dark blue, not grey, same with the url bar of the second window (in which pasting worked).

Two back up the two window theory -> I had copied my user agent string and then closed that window, for this post, then went back to my broken window to see if the arrow keys worked as some claim they won't.  They did, and paste did also, so I realized I must have unbroken focus with the window closing, so I opened more windows to reproduce again.  Again it took 3.  First window, I pasted my string in the url bar and without clicking focus out of the url bar opened another window.  Same thing, pasted and then opened another window without clicking focus away.

In my uneducated opinion it seems like opening these new windows, the *old window* is not giving up focus, and bon echo can only handle focus existing in two windows (text areas? single line inputs?), not 3.
*** Bug 353224 has been marked as a duplicate of this bug. ***
Ok, so I managed to perfectly recreate this bug. The reason it has not been consistant is because it's all about timing. Move too slow, the problem doesn't surface, move too fast, and you get it every time.

READ FIRST...then do it.

1. Make sure all FFs are closed.
2. Open FF from Quick Launch
3. Click on a link and QUICKLY open a new FF from Quick Launch

The problem should now exist in the newly opened FF.

You can close the newly opened FF and repeat without fail.

If you click on a link, and then wait at least 2 seconds, the problem does not surface.
Ah, I'm not alone! Trying not to mist up here.

Want to second that the procedure in #214 works pretty consistently on my machine (XP, single processor, no RDC). But I don't even need to click on a link ("step 3")... I open Firefox window #1 via Quick Launch, then open Firefox window #2 a beat later via Quick Launch, at the moment the window outline of Firefox window #1 begins to materialize.

Have my home page for new browser windows set to:
http://philadelphia.craigslist.org/apa/

(Not a very AJAXy, Web 2.0y, plug-in laden page, to be sure.)

In real world use, my sense is that I tend to experience this bug more often: 1) the longer I use Firefox without closing all Firefox windows (as memory usage/swap file usage creeps up? as swap file access slows the completion of new windows?); 2) when opening a new Firefox window while almost simultaneously mousing to the location bar to start typing a URL, before that new window's home page has finished rendering. But yet again, not nicely reproducible.

Okay, not a programmer, never looked at Firefox code; to me, it's a black box. Some FWIW conjecture: other browser events being handled (page rendering? pointer hovers? etc.) simultaneous to a new window opening(/spawning/initializing/populating menus and toolbars) may interrupt (flush? stomp on?) whatever "to do list" of window-opening tasks need to be complete before clipboard/arrow key functionality is enabled. Uh, perhaps?

Wonder where in the Firefox code a code jockey could attempt to sabotage the clipboard/arrow key functionality for a new window, yet leave all other browser functionality intact. Or, wonder if some debug code would be able to detect when a window found itself in this "no clipboard/no arrow keys" state, and spill diagnostics hinting where and when that window's birth defect occurred.
So the problem here is that the newly created window is activated/focused too early. http://bonsai.mozilla.org/cvsblame.cgi?file=mozilla/toolkit/xre/nsNativeAppSupportWin.cpp&rev=1.25&mark=580#580

Possible explainations of why early activation/focus causes problems can be found in bug 306076 comment 14 and bug 305032 comment 5.
Attached patch Patch for windows — — Splinter Review 
Prevent the early activation of newly created windows and let nsWindow do the job when it's good and ready.

This also fixes bug 269033.
Attachment #241690 - Flags: review?(mats.palmgren)
(In reply to comment #217)
> Created an attachment (id=241690) [edit]
> Patch for windows
> 
> Prevent the early activation of newly created windows and let nsWindow do the
> job when it's good and ready.
> 
> This also fixes bug 269033.

If this still applies to branch (which I believe it does as I run into this occasionally) would it be possible to get it checked in after a bit of testing?

~B

Comment on attachment 241690 [details] [diff] [review]
Patch for windows

Forgot to mention that this patch was tested for Firefox trunk on Windows 2000 and XP.

Also tested for regressions for Thunderbird on Windows 2000 and XP.
Tremendous work, Oliver -- nominating for RC3 or 1.8.1.1.  We will get this fixed for Firefox 2.x if I can help it.

/be
Flags: blocking1.8.1?
Flags: blocking1.8.1.1?
Flags: blocking1.8.1-
Assignee: mats.palmgren → oliver_yeoh
QA Contact: mconnor → nobody
Attachment #241690 - Flags: review?(benjamin)
Just today, I've discovered that the download target setting is a factor in my clipboard problems.  From the beginning of release 1.5 until today, the following has never worked:

1) copy
2) open new browser
3) paste

The only thing I can copy/paste successfully seems to be text in an active text form, like the text I'm typing right now.  But if I'm copying the address bar or the existing text in a web page, it won't be in the clipboard when I open a new browser.

Also, I've been experiencing very irritating focus problems while trying to type in a form.  When this happens, the arrow keys and home/end will not work.  The only way I can move the cursor is by typing or using backspace.  If I type a "/" or an apostrophe ('), then the find dialog will pop up.

However, yesterday my download setting of "download all files to desktop" was changed to "ask me where to save every file".  And now for the first time ever, copy/paste is working.  Also, I had another episode with the typing problems described above, and as soon as I changed the download setting to "ask for every file", the problem immediately went away and I could type normally.  Something weird is apparently going on with the download setting.
We're not going to touch focus this late in the game for 2.0, hopefully we'll get this for 2.0.0.1
Flags: blocking1.8.1? → blocking1.8.1-
(In reply to comment #222)
> We're not going to touch focus this late in the game for 2.0, hopefully we'll
> get this for 2.0.0.1

Even though this is a regression?  Is the fix not a trivial fix?

~B

A regression from what? The bug was reported against Firebird 0.6.1 and has had recurring reports all the way through 1.5.0.x.

Although, the patch is small, the potential risk for regressions is big. See bug 259816, for instance, which touched similar code and took seven additional patches over two months to fix all the regressions.
Mats, Benjamin: please review or appoint better reviewers.

This patch should go into the trunk ASAP, and be baked well such that it's an easy sell for Firefox 2.0.1 (Gecko 1.8.1.1).  I'll back it to the hilt if it proves to work well without the need for seven followup patches.

/be
Comment on attachment 241690 [details] [diff] [review]
Patch for windows

robstrong has better winapi chops than I.
Attachment #241690 - Flags: review?(benjamin) → review?(robert.bugzilla)
Comment on attachment 241690 [details] [diff] [review]
Patch for windows

Looks good and thanks!
Attachment #241690 - Flags: review?(robert.bugzilla) → review+
Comment on attachment 241690 [details] [diff] [review]
Patch for windows

Works fine for me too, r=mats. Nice work Oliver!
Attachment #241690 - Flags: review?(mats.palmgren) → review+
Need someone to help check this in, please?

Thanks.
Comment on attachment 241690 [details] [diff] [review]
Patch for windows

I can land it, need an sr+ first though...
Attachment #241690 - Flags: superreview?(brendan)
Comment on attachment 241690 [details] [diff] [review]
Patch for windows

sr=me -- nominating for 1.8.1.1 to get it on the radar.

/be
Attachment #241690 - Flags: superreview?(brendan)
Attachment #241690 - Flags: superreview+
Attachment #241690 - Flags: approval1.8.1.1?
Comment on attachment 241690 [details] [diff] [review]
Patch for windows

could someone please explain why http://bonsai-stage.mozilla.org/cvsblame.cgi?file=mozilla/xpfe/bootstrap/nsNativeAppSupportWin.cpp isn't being patched equivalently (or just patch it)
Attachment #241690 - Flags: superreview+ → superreview?(brendan)
Comment on attachment 241690 [details] [diff] [review]
Patch for windows

timeless: do *not* reset my sr+ or you will get hurt.

The xpfe code can be patched separately and should not hold up this patch for one second.

/be
Attachment #241690 - Flags: superreview?(brendan) → superreview+
This is the corresponding patch for xpfe and it does fix a similar bug for
SeaMonkey.
Attachment #241966 - Flags: superreview?(brendan)
Attachment #241966 - Flags: review?(brendan)
Comment on attachment 241966 [details] [diff] [review]
Additional xpfe patch for windows

I'll leave it to SeaMonkey people to nominate for the appropriate branch.

/be
Attachment #241966 - Flags: superreview?(brendan)
Attachment #241966 - Flags: superreview+
Attachment #241966 - Flags: review?(brendan)
Attachment #241966 - Flags: review+
Both patches landed on trunk at 2006-10-11 10:30 PDT

I have filed bug 356314 for remaining problems on MacOSX.

If there are remaining problems on Windows, or regressions, please file new
bugs, thanks.

-> FIXED
Status: NEW → RESOLVED
Closed: 20 years ago → 18 years ago
OS: All → Windows XP
Hardware: All → PC
Resolution: --- → FIXED
bugzilla didn't warn me about the reset. flag conflicts are not listed in midair warnings. this is a known bug. but i only just now got to the bugmail for it. it is not fair to blame bugzilla users (even if they happen to occasionally hack bugzilla) for such bugs.
(In reply to comment #237)
> bugzilla didn't warn me about the reset. flag conflicts are not listed in
> midair warnings. this is a known bug. but i only just now got to the bugmail
> for it. it is not fair to blame bugzilla users (even if they happen to
> occasionally hack bugzilla) for such bugs.

Timeless, sorry to misjudge you -- it looked like you were resetting sr? based on the xpfe code not being patched by the same patch.

/be
OS: Windows XP → All
Hardware: PC → All
Attachment #241966 - Flags: approval1.8.1.1?
Depends on: 357215
Have there been any reported regressions on the trunk?   How much time do we need to be baking before we are clear that this is ok?
(In reply to comment #239)
> Have there been any reported regressions on the trunk?   How much time do we
> need to be baking before we are clear that this is ok?
> 

It has been almost a month now. I think that anything would have shown up by now.
(In reply to comment #240)
> (In reply to comment #239)
> > Have there been any reported regressions on the trunk?   How much time do we
> > need to be baking before we are clear that this is ok?
> > 
> 
> It has been almost a month now. I think that anything would have shown up by
> now.

Yeah, this looks solid.

/be
(In reply to comment #240)
> (In reply to comment #239)
> > Have there been any reported regressions on the trunk?   
> 
> ... I think that anything would have shown up by now.

You would think. Copy, cut and paste, the primary symptoms and focus of the bug (not focus per se) is solid for me (in Thunderbird which is the only place I had seen it) and I can't identify any new significant bugs filed in this area since 2006-10-11.  Except ...

I am seeing unprovoked focus changes - not sure it's tabs or windows - which could be Bug 357215 (I am using VDM), so comments in this bug need to be considered. However I am not sure this phenomena has a common cause or is a regression caused by the recent patch - it could be an old bug or something else entirely - but the behavior is new to me and coincidentally I recently installed the VDM powertoy. 


Removing bug 258285 dependency, someone thought it would fix this bug 220900, which it didn't nor is it related. Perhaps bug 83552 and 254592 fall into the same boat. Not touching bug 357215, which may or may not be related or a regression.
No longer depends on: 258285
Comment on attachment 241690 [details] [diff] [review]
Patch for windows

approved for 1.8 branch, a=dveditz for drivers
Attachment #241690 - Flags: approval1.8.1.1? → approval1.8.1.1+
Comment on attachment 241966 [details] [diff] [review]
Additional xpfe patch for windows

approved for 1.8 branch, a=dveditz for drivers
Attachment #241966 - Flags: approval1.8.1.1? → approval1.8.1.1+
Flags: blocking1.8.1.1? → blocking1.8.1.1+
Landed both patches on MOZILLA_1_8_BRANCH at 2006-11-20 17:36 PST.
Keywords: fixed1.8.1.1
Status: RESOLVED → VERIFIED
verified bug existed in 2006102003 on Windows XP as per <a href="https://bugzilla.mozilla.org/show_bug.cgi?id=220900#c185">comment #185</a>. Found the right timing after about 8 windows. (open window with desktop shortcut, ctrl-v to paste, minimize window to try again).

Using latest 2001 nightly (2006112903) was unable to reproduce after 30 windows.
Keywords: verified1.8.1.1
*** Bug 362457 has been marked as a duplicate of this bug. ***
FWIW, I'm still frequently seeing this bug appear while running the latest 2.0.0.1 version:
Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204 Firefox/2.0.0.1

It seems as though the bug is often triggered by using a hotkey to open Google Desktop, which then launches Firefox in a new window.


(In reply to comment #246)
> verified bug existed in 2006102003 on Windows XP as per <a
> href="https://bugzilla.mozilla.org/show_bug.cgi?id=220900#c185">comment
> #185</a>. Found the right timing after about 8 windows. (open window with
> desktop shortcut, ctrl-v to paste, minimize window to try again).
> 
> Using latest 2001 nightly (2006112903) was unable to reproduce after 30
> windows.
> 


(In reply to comment #248)
> FWIW, I'm still frequently seeing this bug appear while running the latest
> 2.0.0.1 version:
> Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.8.1.1) Gecko/20061204
> Firefox/2.0.0.1
> 
> It seems as though the bug is often triggered by using a hotkey to open Google
> Desktop, which then launches Firefox in a new window.

File a new bug, refer to this one in comment 0, cc: the right people (Oliver, who is my hero for fixing this bug).  If there is a case not covered, it should be a new bug.  If there's an unrelated problem, new bug.  This bug is VERIFIED FIXED.

/be
No longer depends on: 365231
removed dependent bug 311883 which was marked WFM before this bug was fixed, so it's not dependent

removed blocking bug 357215 - not related unless it is shown to be a regression from this bug's patches.
No longer blocks: 311883
No longer depends on: 357215
Flags: blocking1.9?
This bug does not appear to have been fixed, and in fact is cropping up with even more frequency in 2.0.0.3. It's gotten much worse instead of better.

The symptoms I'm encountering include things that have been mentioned in this bug many times. Home/End keys don't work, arrow keys don't work, etc. In addition I've been noticing that if something is highlighted on one tab and you switch to another when this bug surfaces, right-clicking shows a context menu for whatever's highlighted on the previous tab. Shortcut keys won't do anything at all, and the only fix is minimizing the window then restoring it. 

This is awful and extremely frustrating.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
If you have a reproducible issue that still affects Firefox 2.0.0.3, please file a new bug. While this bug's summary (as vague as it is) might describe the symptoms of the issue you're seeing, trying to track all focus related problems in one bug (especially one as large as this one) just leads to trouble.
Status: REOPENED → RESOLVED
Closed: 18 years ago → 17 years ago
Resolution: --- → FIXED
I hate tabbed browsing, and use shift+click on all links I click. I can tell you for sure, that this problem still exists and is prevalent. It effects both of my computers, laptop and desktop; both xp. It also happens on my school and work PC as well.

Coy and paste stops working after a matter of time. Either a memory leak..but doesn't perform like that...more likely a race error with all those windows open.

In fact I'd put money on it being a race error.

In addition any text fields like search bars, behave strangly when the copy/paste problem occurs. You often can't select text, backspace, see the text indicator, use keyboard shortcuts (ctrl+a, home, end, etc).

I hace switched to opera because of this error. Please fix firefox.
joe - this bug did fix the particular case it set out to fix.  Please check to see if there's another open bug that more accurately describes your problem and when it happens (eg https://bugzilla.mozilla.org/show_bug.cgi?id=339465 ) or file a new bug with as much detail as you can provide.
Actually, the purported fix doesn't really address the original bug report.  The original report referenced multiple windows and so does joe's report now.  It looks like something was fixed recently, but not this bug.

See comment 253. One issue was fixed in this bug. If there are other issues, they should be tracked in other (new) bugs. This is how we use bugzilla.

Thank you for your patronizing reply to the user community.

Everyone: It's been several years since I had the machine on which this bug was reproducible, so I can't honestly open a new/equivalent bug with the same symptoms.  Since the problem still seems to be happening, can someone else report a "new" bug about this? Thnx.

If you can describe the steps that can be used to reproduce this issue in the latest version of the software, and there are no other bugs with your steps to reproduce, please do file a new bug. It doesn't matter when it started happening to you.

To folks still seeing the symptoms of this bug: bug 357215 fixed another set of causes of this bug, and has only landed on the trunk (i.e. Gran Paradiso/Firefox 3).  Please try using a recent trunk build and see if that has addressed the problem for you.
Ed - I see you're the original reporter, and while this didn't fix your particular case, this bug ended up being used to fix the case that we could reproduce. We try to avoid this situation, but when the original report doesn't have reliable steps to reproduce (not your fault, this was a hard one to nail down) it can happen.

Please file a new *report* with as much info as possible on when it happens, if it got worse at any point, and if accessibility.typeaheadfind is set to true or false (or it doesn't matter) when it happens, and mention that bug number here so we can follow you over.
This is joe again on 6/16/07 and problem has yet to be resolved by the countless "fixes" that have applied towards it. Has anyone made any real progress in finding a solution to this quite severe bug?

BTW- I switched to opera because of this bug, but I still wish to use FireFox. Upon searching for my problem on Google I was sad to see I was steered back to my post from months ago. 


P.S. I'm depressed now /:


And this is most definitely the same bug that was "resolved" in this thread. the steps the earlier poster wrote:

To reproduce on Windows XP:

1) Open multiple tabs.
2) Select location box text in tab (a)
3) Copy
4) Verify it pasteable in another app
5) Switch to tab (b)
6) Select location bar text
7) Copy
8) Verify text is NOT pasteable in another app
9) Verify that it is impossible to copy/paste any text from the browser
10) Verify that selecting/copying text in another app resets conditions

Tested with: FireFox v0.8
Tested on: Windows XP SP1"

...This would be how you would replicate my current dilemma

Don't spam closed bugs with comments in which you note that you're testing with "FireFox 0.8".  The various related bugs here have been fixed on the trunk (Firefox 3), and, for some particular cases, Firefox 2.  If you want to see if the relevant patches have fixed your problem, you should be testing with one of the Firefox 3 alphas, not an archaic version.
Ok, without the Jarga....  In Mac OS, can it be prevented or fixed...
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: