Apache OpenOffice (AOO) Bugzilla – Issue 17051
URL's copied from Konqueror into OOWriter can't be pasted with normal Paste
Last modified: 2013-08-07 14:38:26 UTC
First, thanks for a truly great product! In evaluating the the 1.1 RC, I have found a couple of bugs,for example OOWriter randomly hanging when saving (don't know how to trace this), but this bugreport is about a problem with pasting a URL into OOWriter that is copied from Konqueror. To reproduce the bug: In Konqueror, right click a hyperlink and select "Copy Link Location". Then try to paste that into OOWriter. After a 10-20 seconds "freeze", OOWriter returns to the state it was before pasting. When trying to paste again, the "freeze" is much shorter (2-3 seconds). I've done a little "investigating" and here are some points that might be of interest: - The error does not occur in OOCalc or OOImpress. - Text selected in Konqueror and copied will paste without any problem. - When right-clicking an image in Konqueror and choosing "Copy Image Location", and then pasting into OOWriter, it will paste the image instead of the URL. (Once again, only in OOWriter.) - When using Klipper, one can "reselect" the link and pasting will work properly. - None of these errors happen when using Mozilla vs OOWriter, or Konqueror vs any other program. My setup is this: Gentoo Linux (up to date), KDE 3.1.2, and the binary OpenOffice from the openoffice.org web page. I'm sorry if this bug report is somewhat messy. If you have any questions at all, I'll be happy to help. -- Thomas
Hi Thomas! As to your present problem, I tried reproducing it under OOo1.1rc2 and Red Hat 8 Linux (via a remote X session to another RH8 desktop). There was a small delay (1 second) when pasting a URL, and the URL didn't show up. This is indeed a usability problem. However, the workaround is to Paste Special rather than Paste. Likewise, with the image, Paste Special gets the URL. I'm updating your issue summary to reflect what I found and confirming it at low priority, even though it's possible it's a problem in Konqueror. We do have to work out these little issues in copy-and-paste so they don't suprise anyone. About the hang problem you mentioned: To debug a hang, run openoffice under GDB, get the problem to happen, and press ^C in the GDB window. Then give the 'bt' command to get a backtrace of the current thread. Then use 'info threads' to list all the threads, 'thread N' to switch to each one, and give the 'bt' command again to get a backtrace of that thread's stack. See http://kegel.com/openoffice for more info. Please enter this as a separate issue. Thanks!
Reassigned to ES
ES: I cannot reproduce the freeze either. Same as Don Kegel's description. ->DVO: (regression) do you rate the graphic problem and the URL problem as having the same origin or do you want an other issue for one of the both?
dvo: I'm finally able to reproduce this... reproduce the insert-graphic or insert-not-at-all problem as reported by Dan and Eric that is, not the freeze. Explanation: With clipboard operations, the copy process puts a number of formats (format names, not contents) into the clipboard. The paste process can examine this lists, and chooses the 'best' format ti can support. E.g., when copy+pasting text, the copy process e.g. text and RTF and HTML into the clipboard. A receiving text editor would choose the text format, while a full blown word processor would choose either of RTF or HTML. The problem is that there are many clipboard formats, even for the same thing. E.g., for a link one might use plain text as format, or a specialized URL format (which has the same info, but additionally informs the receiving app that this is an URL), or as a file (almost the same as URL). Now, what I think happens here is this: When choosing 'copy link location', Konquerer is a little extra friendly, and not only puts the link location as text into the clipboard, but also as a file or URL. Other browser probably only use text; however, for Konquerer as a file+web+everything browser, treating this as a file makes a certain amount of sense. Now... Writer tries to be a little extra friendly, too. If someone puts a file into the clipboard, we try to insert the file. Which works fine with a graphics, and not with not-insertable-formats. So, when Writer examines the clipboard, it finds that a file is better than plain text, and tries to insert it. Works for the graphics; fails for anything else. Only if the user specifically overrides Writer's choice (paste special, text) the text is inserted... Problem #1: That's my hypothesis; I'm not sure yet how to test whether this actually is the case. Problem #2: I'm not really sure what we want to do in this case. If Konquerer actually puts an 'URL' or 'file' into the clipboard, then Writer's behaviour is perfectly sensible... P.S.: Maybe the freeze has to do with which file is being pointed to. If Writer attempts to insert it, it may depend on the exact URL being pasted (or the network connection, for that matter) how much time this process takes. P.S. 2: I'm not really sure this should be targetted as OOo 1.1.1 - There's a new copy-paste-spec on OOo for the 2.0 time frame; this issue might best be handled together with that work.
dvo: Additional info: This seems to have worked for previous versions, so maybe my hypothesis is wrong. Still, changing target to OOo 2.0.
.
dvo->fs: Please have a look at this. The relevant code is in: sw/source/ui/dochdl/swdtflvr.cxx (copy&paste handling in Writer) sot/source/base/exchange.cxx + formats.cxx (format tables) Thanks.
Changed prio to 4
targeting to "OOo Later" in agreement with AMA
Reset assignee on issues not touched by assignee in more than 2000 days.