| Summary: | [test case] Copy and paste fails for certain web pages | ||
|---|---|---|---|
| Product: | [Applications] konqueror | Reporter: | Anders E. Andersen <andersa> |
| Component: | khtml forms | Assignee: | Konqueror Developers <konq-bugs> |
| Status: | RESOLVED WORKSFORME | ||
| Severity: | normal | CC: | beat_fasel, landrews, marwo264, napalm01, ndeb, yanestra |
| Priority: | NOR | ||
| Version: | unspecified | ||
| Target Milestone: | --- | ||
| Platform: | unspecified | ||
| OS: | Linux | ||
| Latest Commit: | Version Fixed In: | ||
| Sentry Crash Report: | |||
| Attachments: | Test case | ||
|
Description
Anders E. Andersen
2003-05-23 10:06:26 UTC
Are you referring to pasting with Ctrl+V to textareas? I can copy and paste fine with the mouse. Yes, the poster is referring to Ctrl+c and Ctrl+v to textareas. The hotkeys for cut/copy+paste functions seem to work rather inconsistantly. It can be very confusing. If you cut/copy+paste with just the mouse, it all seems to work just fine. Subject: Re: Cut and paste in konquerer is weird Anders Ellensh Yes I am talking about ctrl-c, ctrl-v or for that matter you can try the copy option from the edit menu, it doesn't appear to be the shortcut combination itself that fails, but something in the copy function itself. My klipper configuration is (was) like Simon Hepburns config 3: [x] Ignore selection [ ] Sync contents [x] Seperate clipboard and selection I am now using config 1 as it appears to work around the problem. *** Bug 53701 has been marked as a duplicate of this bug. *** Trfy this page also, I couldn't make copy&paste work with the keyboard shortcut nor the menu: http://news.independent.co.uk/digital/features/story.jsp?story=426715 Tested with 3.1.3 Debian Sid, Xfree 4.2. It occurs with many pages. It only works if klipper is configured to synchronize both selection and c&p clipboards. The bug is not new for 3.1.2/3.1.3 Does failure only occur if you first put your text cursor in a form field (bugs #54868 and/or #58287)? Bingo! that is. At least I repeated the test several times. It seems to be the case. I would not go as far as to say that that is the whole issue. Is I said above I have had it fail on slashdot also, without using any form fields. But of course since we seemingly have a bug here with the form fields that is fully reproducable, it might be worth it to focus the efforts on that. Anyway. I can verify that this bug occurs after putting the curser in a form field. This explains why google.com always fails. The cursor is automatically placed in the search field when the page is loaded, and afterwards cut and paste fails for the whole page. I just tried with slashdot, it only fails if I put the cursor in the form. Going back and forth enables copy&paste again. could one of you please do me a favor and summarize where the bug is? I'm majorly confused :) Created attachment 3519 [details]
Test case
A main issue, perhaps THE issue is this:
Putting the cursor in a form field disables the copy function.
Check out the attached test case, which reproduces the problem consistently for
me.
Confirmed that attachment 3519 [details] does the same thing on my computer.
In webpages after selection, I am unable to copy with Mouse by RMB menu :( I want cut, copy and paste in RMB menu in webpages. Comment #14 is irrelevant to this issue. for me it's even more strange: it pasted some former copied text - letting it appear that ^C didn't work That's what happens if you previously succeeded at copying text (that is, before the bug manifests itself). The paste buffer will continue to have whatever it had before. *** Bug 58287 has been marked as a duplicate of this bug. *** *** Bug 71956 has been marked as a duplicate of this bug. *** Just updating. This bug is still around in KDE 3.2.2. I would like to confirm that this (the most infuriating for me :)) bug is still in KDE 3.3beta1. For me it actually happens every day; after having used konqueror for some time the cliboard gets blocked and Ctrl+C -> Ctrl+V does no longer work (ie copying no longer works). The only way is to either restart kde or mess with klipper's settings (I randomly switch some of them off and on :) and the clipboard gets unblocked). I cannot as yet confirm that it happens only with form field as i'm not quite sure how it is triggered (but it is quite likely). Regards Hmm.. For me this appears to work now in KDE 3.3. Please test this. I'm afraid the problem is still there. Yesterday it happened to me again on forums.gentoo.org when I was trying to copy some code - I selected it, chose "Copy Text", tried to paste it somewhere and what was pasted was the previous selection (which blocked the clipboard). The only thing that helps is, as I already mentioned, klipper or restarting kde. With klipper, i usually do something like: 1) clear history 2) copy something (still doesn't work) 3) copy something else 4) switch between the copied text and usually clipboard gets unblocked. (It happens with KDE 3.3). Did you try the test case? Something appears to have changed. Just after I have selected a bit if text I can always copy it now it seems. However if I select a bit of text and then set focus on the text box by clicking on it, so the cursor blinks in the text box, then copy /doesn't/ work with the selection still active. But if you reselect some text again, copy seems to be reenabled. Copy always works on *fresh* selections for me now. Please, can anyone else test this a bit? Huh? I think this is normal behaviour. When you set the focus on a text box the "copy" command refers to the text box because you might want to copy text from the text box. When you click on the page again (outside the text box) the selection is removed. Don't know if we want that but it's okay IMHO. When you select text and click around the page without a reason it's your own fault. Why not copy the text to the clipboard directly afterwards? That's why you probably selected it in the first place or not? So if it stays with the status quo and the selection is deleted anyway when you set the focus to the page again there is no use in keeping the selection when the focus is leaving the page. Perhaps the selection should be removed already as soon as the user clicks inside a text box to avoid any confusion. I have tried the testcase from comment #12 and copy&paste seems to work. So it would seem that that problem is no longer there. However, I do remember, as I wrote, that I selected some code from the site I mentioned (it contained those spaces at the end, I believe they are called 'trailing' or something like that), right-clicked, selected "Copy Text", then tried to paste it in nano and what was pasted was the previous clipboard's content. Then I selected something else, again chose "Copy Text" and tried to paste it and again, the very same thing got pasted. That is why I got the impression that the clipboard got 'stuck' (I'm not sure if the text box on that site was active during that time). I tried to recreate the problem with the very same site and I couldn't. So either there is some other bug (which is rare) or I'm hallucinating or I got it all wrong. Since people don't seem to experience this problem in KDE 3.3 it must have been fixed then. On Sunday 29 August 2004 11:47, rgpublic@gmx.net wrote: > Huh? Huhhuh? > I think this is normal behaviour. Ehh. Yes. I kinda think so too, that's why I am thinking about closing this bug. Are we talking about the same thing here? > When you set the focus on a text box the "copy" command refers > to the text box because you might want to copy text from the text Perhaps. But there is no selection in the text box yet, so shouldn't the selection still be what is copied? Anyway this is irrelevant to the original problem. Is the bug solved or not? > box. When you click on the page again (outside the text box) > the selection is removed. Don't know if we want that but it's okay Seems ok to me. :) But what about the bug? Is it gone? Test test please. It works for me! > IMHO. When you select text and click around the page without a reason > it's your own fault. Why not copy the text to the clipboard directly > afterwards? That's why you probably selected it in the first place or not? Ok, now you lost me completely. What I want to know is if ctrl+c works for you after you have had focus on the text box. Doing that used to completely disable ctrl+c until you reloaded the page. Even if you reselected new text! ctrl+c was disabled! Which is what caused me to file this bugreport in the first place. But for me it works now. Try the test case please. Does it work for you? > So if it stays with the status quo and the selection is deleted anyway > when you set the focus to the page again there is no use in keeping the > selection when the focus is leaving the page. Perhaps the selection > should be removed already as soon as the user clicks inside a text box > to avoid any confusion. I don't understand why you are focussing so much on what is selected?! That was not at all what I was talking about.. Kind Regards Anders E. Andersen Several people have tested this now, and it appears to be fixed in KDE 3.3. Closing.. I have KDE 3.5.9, the problem is still here. When viewing web-pages in Konqueror, it sometimes does not allow to copy text in the main body either in menu or with a shortcut Ctrl+C. At that web-site contents is not protected and these pages can be easily put in the buffer. A typical website where I experience this problem: bash.org.ru. Sometimes menu "Copy Text" is not available, sometimes it is available, but the buffer is still null after copying. This problem appears with the same web-pages, the contents of which could be previously copied. The solution is to reload the web-page. |