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.
Chris, could you look at this? reassigning to saari as p1 for M11.
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.
David, can you figure out what's going on here ...
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.
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.
Putting on [PDT+] radar.
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.
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/
Added scalkins and amusil to cc as this affects IM.
*** Bug 16293 has been marked as a duplicate of this bug. ***
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.
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.
*** Bug 20900 has been marked as a duplicate of this bug. ***
*** Bug 21112 has been marked as a duplicate of this bug. ***
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.
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 copied".
*** Bug 4147 has been marked as a duplicate of this bug. ***
*** Bug 4617 has been marked as a duplicate of this bug. ***
Clearing FIXED resolution due to reopen.
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.
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" :-)
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 macweek.com and CNN.com): Mac OS: Menu items are normally selectable, but ordinary content is irreproducibly not copied. Win32: Cut/Copy/Paste menu items are occasionally not enabled. Unable to consistently reproduce. Linux: (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: http://bugzilla.mozilla.org/show_bug.cgi?id=22176^@^@^@1^@^@^@N,@N,@ ^H^HO,@^@^@^@^@^@^@^@^@X^@^@^@^@^@^@N,@x^H0^@ (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.
Start mozilla go to www.mozilla.org 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 ftp.mozilla.org)
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 GlobalWindow::GetControllers.
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.
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.
*** 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.
*** Bug 21832 has been marked as a duplicate of this bug. ***
[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.
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.
Oy. 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. Thanks!
...is 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.
This should work now, for both content and the url bar
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 http://bugzilla.mozilla.org/show_bug.cgi?id=21185 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 verifying.
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.]