From Bugzilla Helper: User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:0.9.2) Gecko/20010809 BuildID: 2001080910 (Please see http://www.freedesktop.org/standards/clipboards.txt for background to make sense of this report.) There are two relevant "selections" in X; PRIMARY is "the current selection" and CLIPBOARD is "stuff cut or copied or pasted using menu items or key shortcuts." The implication of PRIMARY is that unlike other platforms, the "current selection" is a global concept rather than a per-application concept. That is, if I select in application A, go to application B and select again, then the selection in Application A goes away. Mozilla has a couple bugs in its conformance to the X specs: - if I select in another app, the Mozilla selection does not go away; so it looks like pasting with middle mouse button will paste the Mozilla selection, but really it will paste something else. Confuses me constantly. When the PRIMARY selection is cleared, Mozilla needs to drop its selection so people can tell what middle mouse click is going to paste. This applies to both the location bar and the web content area. - Copy Link Location copies to PRIMARY in addition to clipboard. This is wrong; menu items should not affect the selection. Say that I go to my text editor and select some text. Then I want to paste in a URI to replace that text. So I go to Mozilla and hit Copy Link Location. Then I go back to the text editor - oops, Mozilla stole PRIMARY! So I have to reselect the text I wanted to replace. I grant that I often use the fact that Copy Link Location goes to PRIMARY, and that people would whine a lot if it was changed. This is IMO because other apps are broken and don't have Paste menu items that pull from the CLIPBOARD selection. We need to simply have everyone follow the specs instead of working around the current confusion, or things will never work quite right. However, if we must work around other apps, I would suggest that Mozilla at least render the selection after Copy Link Location. That is, the Copy Link Location item would do the equivalent of first selecting the URI, then activating the Copy menu item from the Edit menu. Then I at least get visual feedback that PRIMARY has been affected, which would be a big improvement. Right now my other selections go away (except the one in the Mozilla location bar, since it's broken), but I don't see a new selection; confusing.

> if I select in another app, the Mozilla selection does not go away; Bug 55437 > I would suggest that Mozilla at least render the selection after Copy Link > Location. That sounds like a really good idea. :)

->selection?

umm not sure this should be me. I think someone with some javascript magic needs to caress this. Someone in apps maybe? I will have to see who to send this to. MJ

bouncing to apps.

->hewitt

I'm not the man to fix unix clipboard issues, somebody else should take this bug.

this is the kind of thing jag loves to fix

-> 1.1

1. What about adding "properties" checkbox/radio "Copy link location copies to... Primary/clipboard?" This way both "normal users" and "X purists" will be satisfied. 2. Related to bug# 93308, bug# 143607 and their dependencies. Seems like they are dup or result of this one,

There is a well defined correct UI here that all modern apps are using, so I'm not sure it should be a preference. Definitely the default should follow the specs and the GNOME/KDE convention, anyhow.

One problem is that there _is_ no way to get the link location into PRIMARY except via "copy link location". For those users who vastly prefer PRIMARY to CLIPBOARD for selection/copy/paste, this presents somewhat of a problem (similar to the one that exists in the JS console, where it is impossible to "select" an entry properly).

> > I would suggest that Mozilla at least render the selection after Copy Link > > Location. > > That sounds like a really good idea. :) <a href="http://foopy.com">foopy</a> If I were to select this text upon clicking "Copy Link Location", it would render "foopy" as selected while "http://foopy.com" would be in PRIMARY. That seems rather confusing, especially since I can manually select that text and have "foopy" in PRIMARY. I guess it's still better than the current situation, as the user can probably keep track of which action caused the text to be selected, and thus what's in PRIMARY right now. If we make Mozilla strictly follow the convention, then things like "Copy Link Location" followed by middle-mouse-click in another browser window or tab (to load that url) will break. For the latter I guess it's just as easy to drag the link to the tab header, and for loading the url in another window I guess one can clear the location bar and paste the url in there. Or we do something like "if the user has shift pressed while clicking on 'Copy Link Location', then copy into PRIMARY instead of into CLIPBOARD" (Windows supports this for deleting files directly instead of putting them into the trashcan).

Good point that "foopy" would be highlighted while the URL would be the actual contents of the selection. Kind of lame. For middle click to go to the selected url, you could always do something like a menu item "go to url on clipboard" or something. Or just the Shift modifier as you say. The basic problem is, the transition state from the old primary-only setup to the correct primary/clipboard setup is a bit broken for users, because some of their apps don't work right. But the current state is also a bit broken, and we're already in the transition (all gnome/kde apps are in the new state for example). So the only way away from the pain is to just start fixing everything, and endure the user complaints until we finish... The clipboard is much faster and more usable if you use the keybindings for it, fwiw. And there are some only-possible-with-clipboard handy features, like selecting something and pasting over it to replace.

>For middle click to go to the selected url, you could always do something like >a menu item "go to url on clipboard" or something. Or just the Shift modifier >as you say. Note, right-click in the link, then move the cursor over the "copy link location", reach for shift, press it, click "copy link location" - Very uncomfortable. I've got an idea that would definitely be more comfortable, but I haven't seen it anywhere else yet, so that would be quite confusing for new users - click LMB on the "copy..." to copy to the clipboard or RMB - to the Primary? What do you think? Completely stupid? >The basic problem is, the transition state from the old primary-only setup to >the correct primary/clipboard setup is a bit broken for users, because some of >their apps don't work right. But the current state is also a bit broken, and >we're already in the transition (all gnome/kde apps are in the new state for >example). So the only way away from the pain is to just start fixing >everything, and endure the user complaints until we finish... Note standard Xterms and thousands of other applications don't have the menu item for clipboard. Also note ctrl-c means something completely different in them. I think this windowsism was a very unfortunate choice. >The clipboard is much faster and more usable if you use the keybindings for it, >fwiw. I strongly disagree: Primary: Select text, middle-click in destination place. Clipboard: Select text, press ctrl-c or "copy", left-click in destination place, press ctrl-v. BTW, I don't use any bloatware like Gnome or KDE, and basic use for "copy link location" is pasting it into aterm (rather simple terminal of my choice) after "wget" (Mozilla's downloader works rather bad on link as poor as my own.) so almost all downloads go through this option. I can't really imagine having to switch to some bloated ugly konsole and selecting "paste" from its pull-down menu each time.

> I've got an idea that would definitely be more comfortable This idea is flawed, since context menus come up on mousedown, not on click. So typical usage is to mousedown, move to the item you want, then mouseup, all with the right button. Note that this leaves no room to do anything with the middle button.

>This idea is flawed, since context menus come up on mousedown, not on click. They come down on both, though using mousedown is more common, since it's faster. But still, even if you opened the menu using mousedown RMB, you may still activate an item by clicking (more precisely releasing) LMB while still holding RMB - in this case instead of clicking, releasing given button would generate distinct event... if this distinction is recognisable, which is quite a different problem. I don't think this feature would be worth rewriting whole context menu event catching code if it isn't.

retargeting