User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:33.0) Gecko/20100101 Firefox/33.0 Build ID: 20141113113219 Steps to reproduce: Set Klipper to "Synchronize contents of the clipboard and the selection" which copies anything that gets selected. Sites that have links that are pre-selected when you left-click on them should also be copied to Klipper when I left click them. An example of such site would be imgur.com which will give you pre-selected links for image uploaded. Here is a video to show the problem https://www.youtube.com/watch?v=w9q-o37ELgs&feature=youtu.be Here is the upstream Klipper bug. https://bugs.kde.org/show_bug.cgi?id=340734 Actual results: No data is sent to Klipper Expected results: Anythingh that is selected should be copied to Klipper is it is set to "Synchronize contents of the clipboard and the selection"
Reading the upstream bug, I don't understand. AIUI middle click normally (ie without Klipper) pastes from the clipboard, not from a magical selection buffer. If the text is selected and e.g. hitting ctrl-c copies it (which it does for me on imgur), I don't understand what you think Firefox should do differently.
Thanks for taking the time to look into it, Gijs. I have set Klipper to copy everything that gets selected. That way I don't have to constantly Ctrl-C over and over throughout the day. Problem with Imgur or ownCloud or any other service, that pre-selects the link/text, is that the link/text gets selected, by a single left-click, but it doesn't get copied to Klipper. Selecting pre-selected-links by single-left-click basically ignores the "Synchronize contents of the clipboard and the selection" of Klipper and it doesnt' get copied. As you can see in the video attached that Chrome honors "Synchronize contents of the clipboard and the selection" setting and simply single-left-click copies the pre-selected-link to Klipper. There is no need to hit Ctrl-C. On Firefox, you have to hit Ctrl-C for Klipper to copy the pre-selected-link So either Firefox is not sending the data or Klipper is copying/accepting the data. Please let me know if I am not clear enough.
What I meant was, this bug needs more technical details indicating what Firefox is or isn't doing (right) here. I am unfamiliar with X's inner workings, but a bit of googling implies that per your expectations, Firefox should be updating the app's PRIMARY selection clipboard, and isn't doing that here. I don't know what causes that to not happen. The bug could be anywhere from the DOM methods that these websites are using to the GTK code that deals with X. Either way, this bug would really benefit from a reduced testcase that reproduces the problem, and more technical details as to what is/isn't happening (instead of me guessing :-) ).
Component: Untriaged → Untriaged
Product: Firefox → Core
Hi Sudhir, As I can see, the video describing the problem is no longer available (https://www.youtube.com/watch?v=w9q-o37ELgs&feature=youtube). Could you please provide a reduced test case example? You can find useful information at https://wiki.mozilla.org/QA/Minimal_Test_Cases and https://developer.mozilla.org/en-US/docs/Mozilla/QA/Reducing_testcases. If you can't provide that could you, at least, give the exact steps to follow (which links you click on, etc).
I have no idea what a test case is. I have moved on. Thanks.
Status: UNCONFIRMED → RESOLVED
Last Resolved: 3 years ago
Resolution: --- → INVALID
Moving from Core::Untriaged to Core::General https://bugzilla.mozilla.org/show_bug.cgi?id=1407598
Component: Untriaged → General
You need to log in before you can comment on or make changes to this bug.