98984 - [X11] Location bar and Copy Link Location menu item don't properly use X selections

Status: NEW

(Core :: DOM: Selection, defect, P5)

Description

[Havoc Pennington]

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.

Comment 1

[Boris Zbarsky [:bzbarsky]]

> 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.  :)  

Comment 2

[sairuh (rarely reading bugmail)]

->selection?

Comment 3

[mjudge]

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

Comment 4

[mjudge]

bouncing to apps.

Comment 5

[Peter Trudelle]

->hewitt

Comment 6

[Joe Hewitt (gone)]

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

Comment 7

[Joe Hewitt (gone)]

this is the kind of thing jag loves to fix

Comment 8

[jag (Peter Annema)]

-> 1.1

Comment 9

[Bartosz Wucke]

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,

Comment 10

[Havoc Pennington]

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.

Comment 11

[Boris Zbarsky [:bzbarsky]]

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).

Comment 12

[jag (Peter Annema)]

> > 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).

Comment 13

[Havoc Pennington]

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.

Comment 14

[Bartosz Wucke]

>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.

Comment 15

[Boris Zbarsky [:bzbarsky]]

> 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.

Comment 16

[Bartosz Wucke]

>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.

Comment 17

[Vedran Miletic]

retargeting

Comment 18

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months, so the assignee is being reset.

Comment 19

[Jeff Fortin]

Shouldn't this ticket be marked as a blocker of the meta bug #1743366?