Closed Bug 14026 Opened 21 years ago Closed 20 years ago

Copy/Paste/Cut (etc) disabled within Browser


(Core :: XUL, defect, P1, blocker)






(Reporter: elig, Assigned: sfraser_bugs)



(Whiteboard: [PDT+] 1/28)

In today's builds (checked Linux, Mac & NT 4), all Editing-related items under
the Edit menu are disabled.

Of course, this renders it impossible to verify, write, or follow up on any copy/
paste bugs.

If this could be fixed as soon as possible, it would be most appreciated.
Assignee: trudelle → saari
Priority: P3 → P1
Target Milestone: M11
Chris, could you look at this?  reassigning to saari as p1 for M11.
Blocks: 14356
Blocks: 13873
Assignee: saari → don
paste works, but the menu item is not shown enabled. Now then...

There are two nodes with id="cmd_copy". This is a bug. There is one in
navigator.xul (and other xul files), and one in globalOverlay.xul

Don, I leave it to one of your team to figure out which is the right node to
keep. But it looks like you want the one in globalOverlay.xul, based on looking
at the XUL and tests.
No longer blocks: 13873
Assignee: don → davidm
David, can you figure out what's going on here ...
Blocks: 12541
adding myself to cc: list.
talked to hangas and we have to wait for an ender controller and then this
should magically work. He also mention he thought Radha was doing this also.
QA Contact: beppe → elig
Blocks: 12691
Summary: Copy/Paste/Cut (etc) disabled in today's build → [DOGFOOD] Copy/Paste/Cut (etc) disabled in today's build
Added "[DOGFOOD]" to get this bug on PDT radar. When I'm trying to use SeaMonkey
for daily work, I have to copy the current url from the page, load 4.7, and then
copy out some big piece of text to go into a mail message, etc.
Depends on: 12022
add dependency
Whiteboard: [PDT+]
Putting on [PDT+] radar.
Target Milestone: M11 → M13
m13 due to dependancy
*** Bug 17577 has been marked as a duplicate of this bug. ***
OK, if buster can get bug #12022 fixed (and I mean more than a day) before M12,
then we can move this back to M12 as well.
Whiteboard: [PDT+] → [PDT+] 11/26 completion
Target Milestone: M13 → M12
David, buster sez that he'll have bug #12022 fixed no later than 11/19 so I
moved this one back to M12 and put a 11/26 completion date on it.  Yeah, I know
11/26 is Turkey Day, but jar wants the week ending dates for schedules.  This
means you'll need to get this completed by 11/24.  Can you do that?  If not,
let's move this out to 12/3/
Summary: [DOGFOOD] Copy/Paste/Cut (etc) disabled in today's build → [DOGFOOD] Copy/Paste/Cut (etc) disabled within Browser
Added scalkins and amusil to cc as this affects IM.
Blocks: 19423
*** Bug 16293 has been marked as a duplicate of this bug. ***
Whiteboard: [PDT+] 11/26 completion → [PDT+] 12/3 completion
Move the expected completion out to 12/3 since buster's current set to changes
to bug #12022 don't seem to solve the problem yet.
Blocks: 20203
Blocks: 20348
Whiteboard: [PDT+] 12/3 completion → [PDT+] 12/10 completion
Move completion target from 12/3 to 12/10 since buster has re-assigned us bug
#12022.  And bug #12022 is gated by bug #2253 which will not be completed until
12/3.  Ugh.
I checked in the code to enable cut/copy/and past in text areas. Single line edit
fields are waiting for a controller. There are also appear to be some bugs in the
text area controller. I'll wait a bit before marking this fixed although I think
my work is done.
Still have to do the hmtl content area. This requires some XPToolkit work to be
done. I have a controller which should work in my tree.
Blocks: 20870
*** Bug 20900 has been marked as a duplicate of this bug. ***
*** Bug 21112 has been marked as a duplicate of this bug. ***
Assignee: davidm → trudelle
Assignee: trudelle → davidm
reassign back to me
Paste does not work in Win98 1999121308 mozilla build.  Appears to work fine for
Linux6 & MacOS86 of same build date.
I checked in a commented out version of the dom controller so that mjudge and
company can work on some related stuff. The enable and disable routines are not
being called for some reason. saari was going to look at that
copy now works in browser content areas.
Closed: 20 years ago
Resolution: --- → FIXED
copy now works in browser content areas.
Really? Has this been checked into the main tree?

The "Copy" menu items (and keyboard shortcut) are both inactive on the 1999121408
Linux & Win32 builds. (Works fine on Mac OS.)
hmm it works on my linux build that I did last night and on mjudges windows box.
I don't know how to install nondebug builds on linux so I can't verify. Does the
edit field ( url bar ) or selection in a mail message work?
Saw the same thing on Don's linux machine. Will investigate a bunch more
It's working well for me in the browser window on my linux build today, except
that in the url bar (or presumably, other text fields if any exist), I have to
do the multiple-click sequence to get the focus there and get the menu enabled,
due to bug 21610.
Using today's builds (all 3 platforms), I'm seeing the menu items enabled ---
however, copy doesn't work within the browser content region on many pages.

Not sure if 12022 needs to be re-opened, or if a new Dogfood bug should be
written for davidm, but will do one of the two in the next 60 minutes. ;)
Broke off the problem of Browser content copy/paste not working on some pages
into a new bug --- 21832, "[DOGFOOD] Browser content frequently cannot be
Blocks: 22176
*** Bug 4147 has been marked as a duplicate of this bug. ***
*** Bug 4617 has been marked as a duplicate of this bug. ***
I'm seeing this again in the 1/3 and 1/4 linux builds.  When I first bring up
the browser window, everything works, but soon (going to Tinderbox from the
menubar bookmarks menu usually does it) I'll get into a mode where key events
are ignored, and hitting things like Page Down gives me the message: JavaScript
Error: TypeError: controller has no properties
Resolution: FIXED → ---
Clearing FIXED resolution due to reopen.
Assignee: davidm → hyatt
OS: All → Linux
reassigning to hyatt ( feel free to pass it to who ever does unix events).
Marking Linux only since I can't reproduce on Mac or Windows builds.
OS: Linux → All
I see this on the Mac, as well, using a build from yesterday.  I don't see it on
Windows.  Changing platform back to All (since there's no setting for "All but
Windows" :-)
Assignee: hyatt → saari
Whiteboard: [PDT+] 12/10 completion → [PDT+]
Target Milestone: M12 → M13
I'm seeing this too. reassigning to saari, cc'ing hyatt, targetting M13,
clearing estimated fix date (please set again).
Incidentally, this isn't just a key binding problem.  The menu item Edit->Copy
doesn't do anything either.
On the mac once I give the html content area focus it seems to work for me. I
can't figure out where the focus goes after loading a new page. There is the
problem that page up and page down when the focus is in the editfield should
really apply to the content area but that is a separate bug.
On Linux, clicking in the content area doesn't help, either with copy or with
page up/down.
Using the 2000010608 build (surfing around and

Mac OS:
	Menu items are normally selectable, but ordinary content is irreproducibly
not copied.

	Cut/Copy/Paste menu items are occasionally not enabled. Unable to
consistently reproduce.

	(deferring to Akkana's comments from 2 hours ago)
...I note that using the 2000010608 builds on Win32/Mac OS/Linux, if you:
	* launch the browser (exit it if it's already running, and then re-launch)
	* select text in the URL window
	* Open the Edit menu

...neither Cut nor Copy are enabled. (I think davidm mentioned this for Mac OS.)
Neither Hyatt nor myself changed anything that would have broke this again, so if anyone else knows what might have changed, please speak up.
I'm going to need help figuring this out. Ender seems to have its own ideas about
what should be enabled and when. I notice Paste is enabled when nothing is on the
clipboard for example.

Who wants to work on this?
I don't think this is an Ender issue -- it works fine in all the editor windows.
 I'm not sure how the browser window controller updating works, though.
Hrm, ok. In my current Mac build the Cut/Copy/Paste seem pretty reasonable until
I start messing with the URL bar, thus my ender comment.
On Linux, at least, Copy from the browser's content area hasn't worked since
last year.  I thought I'd heard the same from Mac users.
I just tried it, and it worked for me on MacOS. Running my linux and windows
builds right now, so I'll look at those ASAP.
Copying from text widgets and from the content area doesnt work at all in Linux.

Choosing "Copy Link Location" from the context menu over a link, then pasting

elsewhere copys the link, and a great deal of junk, that looks nastily like

random bits of memory:^@^@^@1^@^@^@N,@N,@


(I have removed extended char's incase some of you have sensitive mail clients)
I can start looking at this too.
I just tried this out on my RedHat 6.0 system. Highlighting text and
choosing the "Copy" command from the "Edit" menu did copy text out
of the browser. The only problem with this is that it is totally
different from Netscape 4.0 and all other X based applications.
Just highlighting the text should be the same as a "Copy" operation
under Linux (and any other UNIX like system that uses X). If linux
folk are forced to select and choose "Copy" from a menu, there are
going to be really unhappy.
So this is working, weird X conventions withstanding?

I did the same thing (copy with menu command) on my linux box and it worked for
me too.
No, it's not working.  It works initially before you set the focus anywhere
else, but start messing with the focus and it'll stop working and, usually,
never come back.
Blocks: 22528
Start mozilla
go to
highlight text in content window
go to file menu, "copy" is not enabled.

however, if i play games with unhighlighting the text, and clicking
back and forth several times between the url bar and content window
then I can eventually get text copied to the clipboard. (This is with
today's nightly build from
So where is the controlller for these commands? I need to start littering debug
code to figure out what is happening.
nsGlobalWindow.cpp. nsDOMWindowController. The controller is created in
Blocks: 21832
I'm doing related work in composer, and am getting somewhat stuck.
Simon, what are you working on? I just added a bunch of debug code on my Mac

build, just as a sanity test, and the command dispatcher is definitely calling

UpdateCommands at the appropriate times, and the commands are enabling/disabling.
Blocks: 4722
Target Milestone: M13 → M14
Moving to m14. If this is (still) blocking someone, please add a comment saying
who is blocked from doing what.
Blocker for 22528, 4722; general cut & paste.
If it's not m13-able then so be it.
Other dependencies are listed for this bug in
the dependency list.
Oh we have a twisty maze of copy & paste bugs. All these are ultimately dependent
on what hyatt describes at the bottom of 20471, that saari has to move the
command dispatcher.
Is there a bug on moving the command dispatcher?  20471 only has one dependency
and it's marked fixed.
Whiteboard: [PDT+] → [PDT+] 1/28
Blocks: 24854
Keywords: beta1
*** Bug 22384 has been marked as a duplicate of this bug. ***
Give me a bug on moving the dispatcher.  I don't think there is one.
Blocks: 25824
*** Bug 21832 has been marked as a duplicate of this bug. ***
No longer blocks: 25824
[Note to self: be sure to also verify 21832 upon verifying this bug.]
pardon the spam: adding me to cc'list as this touches on my area.
Putting dogfood in the keyword field.
Keywords: dogfood
Summary: [DOGFOOD] Copy/Paste/Cut (etc) disabled within Browser → Copy/Paste/Cut (etc) disabled within Browser
Blocks: 26981
All the cases I know of that cause this horkage seem to be fixed by the checkin 
Hyatt and myself just did. It fixed an interaction between the command dispatcher 
and focus.

Marking fixed until someone comes up with a new test case.
Closed: 20 years ago20 years ago
Resolution: --- → FIXED

For one thing, the focus-related problem blocking copying browser content 
described by trudelle in 21832 (1999-12-16 09:00) is still occuring on this 
morning's build. (only checked Mac OS)

Since 21832 is marked as a duplicate of this bug, I'm re-opening this bug, even 
though the problem has nothing to do with menu items being disabled. 

Of course, please feel free to re-resolve this one and re-open 21832. 

Resolution: FIXED → --- the focus issue trudelle described covered by 12051, or is that a different 
focus problem?

If it's the same thing, then I think this bug can be marked as resolved. (Have 
went through the first half-dozen duplicates, and they're all fixed other than 
the focus problem.)
There are a number of things still to be done here; focus is one issue, but there 
are also some underlying code pieces that still have to be fixed. I'll mark the 
bug fixed when I think it's done.
Let's confine this bug to the originally reported problem.  I think that focus
issues and underlying code should only keep this bug open if the original
problem still exists.  If it does not, then new bug reports should be filed for
these other problems.  I see at least one case where the original problem still
exists, at least on Win98 using comm opt bits, and one that should perhaps be a
new bug:
Copy some text from a web page. 
Select part of the URL in the URL bar.
Expected result: copy and paste enabled
Actual result: Paste enabled, copy greyed out but still enabled.
Select some text in the web page.
Click in the URL bar, leaving a caret but no selection.
Expected result: only paste enabled
Actual result: Cut, Copy and Paste enabled.
Peter, also note bug #25714, which sounds like a variant of the first issue that 
you mention.
*** Bug 27068 has been marked as a duplicate of this bug. ***
For clarification, all the cut, copy and paste keybindings seem to be working 
properly, which means that the command dispatcher is working properly, which 
means that focus is working properly.

So, I think the menus enabling/disabling is the last issue
Be careful here.  Input fields and text areas don't use the command dispatcher. 
They use XBL.  Cut/copy/paste will work using key bindings in input fields and 
text areas without the command dispatcher necessarily working perfectly.

I happen to think that the command dispatcher is largely working well at this 
point anyway, but you can't verify that any more when using key bindings on 
input fields and textareas.

Okay, good point. So are 26882 and 27661 XBL as well?
Simon, you said you're working on this, here is the uber bug.
Assignee: saari → sfraser
This should work now, for both content and the url bar
Closed: 20 years ago20 years ago
Resolution: --- → FIXED
Per trudelle's comment that "Let's confine this bug to the originally reported 
problem.", I'm re-opening 21832, which I'm seeing after doing a quick check on 
the 2.17.00 Mac OS build.
Outside of 21832, I don't see any problems in the current builds after about 20 
minutes of investigation.

Peter Trudelle & Company: This bug touched on a huge number of issues --- are any 
of you still seeing problems? If not, I'll go ahead and mark this as Verified on 
Monday. Thanks!
On NT, I'm unable to copy/paste from mail messages in the normal mail display. 
It works if I double click on them to bring them up into a browser window. 

Copy/paste from browser windows seems fine except that when you have something
highlighted in the browser window and then highlight text in the url bar, the
text in the browser window doesn't unhighlight. (this doesn't prevent
copy/paste though) (I tried both ctrl-C and menu)

Please direct me to the proper bugs if this isn't right.
I also am unable anything in mail windows.  It's only in mail, meaning it's not
this bug.  Has anyone filed a bug on the mail window problem yet? 
looks like I'll reopen for 
mail after checking it out.
Answering my own question: 21832 was just reopened on an issue which I think is
the same one causing inability to copy from the mail window.
Inability to copy from mail 3-pane window is bug 19428, which I am just about to 
check in a fix for.
I believe that the second selection issue endico raises is covered by 7527, which 
is marked duplicate of 7465. Left note in 7465 to check that scenario when 
Since the originally reported problem is fixed, and no new issues were raised by 
the zillion people CC:'d on this bug, I'm marking this as Verified.
[Endico's second issue is known, but didn't have an active bug report. Wrote it 
up as 28999.]
No longer blocks: 20203
No longer blocks: 20870
No longer blocks: 22176
You need to log in before you can comment on or make changes to this bug.