Bug 187403

Summary: Copy via CTRL+C stops working on websites using frames
Product: [Applications] konqueror Reporter: Thomas Jarosch <thomas.jarosch>
Component: generalAssignee: Konqueror Developers <konq-bugs>
Severity: normal CC: anj.tuesday
Priority: NOR    
Version: 4.2.1   
Target Milestone: ---   
Platform: Fedora RPMs   
OS: Linux   
Latest Commit: Version Fixed In:

Description Thomas Jarosch 2009-03-17 15:02:38 UTC
Version:            (using KDE 4.2.1)
OS:                Linux
Installed from:    Fedora RPMs

Hello together,

copying a marked text to the clipboard does not work if you are on a website using frames.
When I select "copy" via the mouse context menu or via "Edit -> Copy" everything is fine.
Otherwise the text won't be copied. 

It has to be normal text or links for it to go wrong, copying from text edit controls works fine. Also happens on KDE 4.2.0 and KDE 4.1.x.

Comment 1 Thomas Jarosch 2009-03-17 15:12:27 UTC
To aid debugging, here's a page with a frame on the right: www.k10k.net
Comment 2 Thomas Jarosch 2009-07-09 10:56:19 UTC
Hmm, could anyone please be so nice and test if this is atleast reproducable?

I can still trigger it on KDE 4.2.4.
Comment 3 anj.tuesday 2009-08-02 16:02:00 UTC
Me, too. Using KDE 4.2.98 (4.3 RC3), Kubuntu 9.04. I can copy using the context menu, I can paste using a middle-click, but Ctrl-C still doesn't do anything (perceptible).
Comment 4 Thomas Jarosch 2009-08-03 10:47:38 UTC
I did some further testing: The problem didn't occur with a KDE 4.3.0RC2 live CD. After that I created another user on my KDE 4.2.4 box with a fresh .kde directory and voila, it's working too.

I suspect this is a configuration issue that appeared after a KDE 4.1.X to KDE 4.2.X upgrade as I tend to keep my .kde directory when I upgrade KDE if possible.

I tried to find the broken config file by deleting selected files in ".kde/share/config" with names like "konquerorrc", but I wasn't able to isolate the source of the problem yet.
Comment 5 Thomas Jarosch 2009-10-07 14:12:09 UTC
Just upgraded to KDE 4.3.1 and killed the .kde directory. Still seeing the issue.

Comment 6 Thomas Jarosch 2009-10-07 22:53:23 UTC
Ok, I gave this a little debugging:

- KHTMLPartBrowserExtension::copy() -does- get called
  -> Redirects control to "callExtensionProxyMethod( "copy()" );"

If I comment out the redirect to callExtensionProxyMethod( "copy()", I found out that KHTMLPart::selectedText() returns no text. Dunno if this is a valid thing to do, but it can't get much worse than it is :)

I digged down further in KHTMLPart::selectedText() and saw this piece of code:

const Selection &sel = d->editor_context.m_selection;
DOM::Node n = sel.start().node();

n.isNull() is true if I use the CTRL+C approach. If I use the context menu of the right mouse button, n.isNull() is false and the text gets correctly copied.

Now I'm stuck.
Comment 7 David Faure 2009-10-08 01:26:27 UTC
SVN commit 1032495 by dfaure:

Repair copy (and cut and paste) in frames (and iframes). Was two bugs in one:
 * another instance of wrong invokeMethod() calls after the Qt3->Qt4 porting.
 * emitSelectionChanged() (called from mouseReleaseEvent in the toplevel khtmlpart)
  was disabling "copy" again after the active frame had enabled it.
Fix will be in KDE 4.3.3 and later.
BUG: 187403

 M  +4 -8      khtml_ext.cpp  
 M  +8 -4      khtml_part.cpp  

WebSVN link: http://websvn.kde.org/?view=rev&revision=1032495
Comment 8 Thomas Jarosch 2009-10-10 16:58:33 UTC
Just for the record: A CTRL+C issue with readonly form widgets has been fixed, too. Works even after using the back button/page reload ;) Thanks again, David!