35835 - RFE "copy URL" option on right-clicking bookmark in manage bookmarks window

Status: VERIFIED FIXED

(SeaMonkey :: Bookmarks & History, defect, P3)

Description

[André Langhorst]

It should be possible to copy the URL of a bookmark right-clicking it.
In addition to "new bookmark","new folder","new sep","del bookm" and
"properties" options there should be an option "copy url"

Comment 1

[Sean Richardson]

This would be a direct cognate of the "Copy Link Location" item on the
context menu for a link in the main browser window. 

This would be useful for copying URLs to another app without needing to load 
the Bookmarked page first. The same info is always available in the Properties
dialog, but this would be much more convenient, as well as surer for those who
don't always type ctrl-c every time they mean to.

Comment 2

[verah (gone)]

S/b "copy link location" as in 4.x

Comment 3

[Peter Trudelle]

[nsbeta2+] will take this if done by 5/16

Comment 4

[don]

Move to M19 target milestone.

Comment 5

[leger]

Putting on [nsbeta2-] radar. Removing [5/16]. Missed the Netscape 6 feature 
train.  Please set to MFuture.

Comment 6

[verah (gone)]

Nav triage team: [nsbeta3-]

Comment 7

[Sean Richardson]

Setting Milestone to "Future" per 2nd last comment, and adding "helpwanted"
keyword per entire history of this RFE.

Comment 8

[Daniel Veditz [:dveditz]]

Adding nsbeta3 keyword to bugs which already have nsbeta3 status markings so 
the queries don't get all screwed up.

Comment 9

[Sean Richardson]

Adding 4xp keyword: NN 4.x has this feature, as "Copy Link Location" on
the context menu for a bookmark in the Bookmarks window. IE5 also has a "Copy"
item on the context menu for favorites in its sidebar.

Comment 10

[Blake Ross]

Reassigning 79 Bookmarks bugs to Ben.  I was told this was going to be done 
shortly about two months ago, but it clearly hasn't been.  I think that's long 
enough for all these bugs to remain assigned to nobody.

Feel free to filter all this spam into the trashcan by looking for this string 
in the message body: ducksgoquack

Comment 11

[Ben Goodger (use ben at mozilla dot org for email)]

*** Bug 35942 has been marked as a duplicate of this bug. ***

Comment 12

[Ben Goodger (use ben at mozilla dot org for email)]

Clearing statuswhiteboard cruft, nominating for nsbeta1. 

Comment 13

[Marcia Knous [:marcia]]

Netscape Nav triage team: this is a Netscape beta stopper.

Comment 14

[Fabian Guisset]

*** Bug 71051 has been marked as a duplicate of this bug. ***

Comment 15

[Sean Richardson]

A beta-stopper (Keyword: nsbeta1 added 2001-01-11) with a target milestone
of "Future"? And a severity of "enhancement"? Adjusting latter, due to 4xp.

Comment 16

[Gervase Markham [:gerv]]

nsbeta1 is a beta1 nomination, not a beta1 acceptance.

Gerv

Comment 17

[Gervase Markham [:gerv]]

Ben G: 

I've got this working apart from the actual copying to the clipboard. Now 
there's code to do this in nsContextMenu.js, but I can't see an easy way to use 
it without copy and paste. nsClipboard.js only currently supports reading - is 
there any possibility that might change in the near future? That would be the 
Right Thing, IMO...

Gerv

Comment 18

[Paul Chen]

nav triage team:

Nice to have, but not a beta stopper now. Marking nsbeta1-

Comment 19

[Gervase Markham [:gerv]]

OK, I have this working again. Just looking for a touch of UI input from mpt
(private mail sent) and I'll be right with you...

Gerv

Comment 20

[Matthew T (active 1999-2002)]

Proposal for bookmark context menu:

  _Open
  Open in _New Window
-----------------------------------------
  _Copy Link Address
  _Duplicate
  _Rename ...
  {Send _to Recycle Bin|Move to _Trash}    [for now, `Dele_te']
-----------------------------------------
  Propert_ies ...

Comment 21

[Gervase Markham [:gerv]]

I'm not going to make the mistake of implementing an mpt idea before it's been
checked by ben and blake ;-), so here's a patch which adds the new menu item in
approximately the right place (above "Copy"), given the spec.

I've added the menu item for IE Favourites as well. As I test on Linux, I have
no idea if that will work - someone feel free to test, or we can check it in and
let QA do it. It's no big deal.

Gerv

Comment 22

[Gervase Markham [:gerv]]

Attachment: Patch v.1

Comment 23

[Håkan Waara]

r=hwaara

Comment 24

[Gervase Markham [:gerv]]

No reason we shouldn't have this for 0.9.1 - people moaned about not having it
in NS 6. r=hwaara patch coming right up...

Gerv

Comment 25

[Gervase Markham [:gerv]]

Attachment: Patch v.2

Comment 26

[Alec Flett]

sr=alecf

Comment 27

[Gervase Markham [:gerv]]

Checked in.

Gerv

Comment 28

[Ben Goodger (use ben at mozilla dot org for email)]

Actually, I disagree with the way this bug was fixed. I believe Copy should "Do 
The Right Thing" when copying data to the clipboard. It was written to do so, 
but a typo on my part has broken the functionality, causing people to mistakenly 
want for a Copy Link Location item.

Copy should copy the bookmark to the clipboard in as many data flavours as it 
understands (moz/bookmarkclipboarditem, text/html, text/unicode). Applications 
that want to receive a certain flavour can obtain it. In 99/100 cases, this 
application-level flavour-hand-shaking will be correct. 

Comment 29

[Ben Goodger (use ben at mozilla dot org for email)]

Attachment: Best fix. (Add text/unicode data properly)

Comment 30

[Blake Ross]

sr=blake

Comment 31

[matt]

r=matt

Comment 32

[Ben Goodger (use ben at mozilla dot org for email)]

This patch checked in, however I need to finish and get review for 81767 
(tonight) before I can remove the menu items as the changes overlap files. 

Comment 33

[Sean Richardson]

Quoting from above:
  ------- Additional Comments From Ben Goodger 2001-05-22 17:03 -------
  Actually, I disagree with the way this bug was fixed. I believe Copy should 
  "Do The Right Thing" when copying data to the clipboard. ...
  Copy should copy the bookmark to the clipboard in as many data flavours as it 
  understands (moz/bookmarkclipboarditem, text/html, text/unicode). Applications 
  that want to receive a certain flavour can obtain it. In 99/100 cases, this 
  application-level flavour-hand-shaking will be correct. 

But when the user goes to paste, what is the right thing - pasting the 
Title-URL tuple, or just the URL? Obviously for moz/bookmarkclipboarditem and 
text/html, what is wanted will always be a tuple; for consistency, the "Copy"
item should place the tuple in text/unicode as well. For Mozilla to place
just the URL in the plain text flavour, like NN 4.x did, would greatly
incovenience users who want to paste both the Title and URL into a text file
or (text-only) mail message (the user would have to go back and get the Title 
separately -- and bug 81767 will make the user go to "Properties" dialog for
that, making it just as painful in Mozilla as it was in NN 4.x).

If in addition to a "Copy" item a "Copy Link Location" item exists the user 
can trivially choose the former for the tuple, or the latter if only the URL
is wanted. This also preserves another sort of consistency: everywhere else
a visible object appears in the entire Mozilla suite from which a URL can be
extracted, the context menu for that object includes a "Copy Link Location" 
item. Additionally, this item will serve those who want to paste just the URL 
of a bookmark into a context where the text/html flavour would be extracted if
available, like Composer in HTML mode.

Without both items, a choice must be made as to whether the tuple or just the
URL will be placed in the text/unicode flavour on a "Copy", by Mozilla, at 
compile time, when nobody knows what the user may need in a given instance.

As neither choice can be correct for all users all of the time, and choosing  
between "Copy" and "Copy Link Location" is trivially easy for the user to do 
according to current needs, there is no good reason not have both.


Aside from that, Ben, if you do not want a "Copy Link Location" item, the 
correct resolution for this bug would be WONTFIX, *not* checking in a patch
for this bug that has that effect, confusing the record. What would someone
think seeing FIXED on this bug if the fix is to check in your patch? 
Sheesh. If you want to throw away Gerv's good work, please veto this RFE and 
include your one-liner in a patch for another bug, so people will be able to 
tell what happened here without reading the entire bug!

Comment 34

[Ben Goodger (use ben at mozilla dot org for email)]

I believed the ability to copy the location of a bookmark to be orthogonal to 
this bug report, which was filed back when there was /no/ way to copy the url of 
a bookmark (other than copy it around in the bookmark window). 

I think the most likely case is to want to copy the URL, so that's what's sent 
as text/unicode. The title can be obtained from the properties dialog. 

Comment 35

[Ben Goodger (use ben at mozilla dot org for email)]

Old code gone. Fixed (again). 

Comment 36

[Sean Richardson]

I, for one, always have used "Copy Link Location" in NN 4.x's Edit Bookmarks
window, when I want to paste the URL, because that's the same item used for the 
same function everywhere else in the Communicator suite. Anyone who has
copied URLs from the browser window in Mozilla or its ancestors is likely to
look for "Copy Link Location" first when that is what they want.

I'd use "Copy" to get both parts of the bookmark to paste into a plaintext 
context if it worked (in either 4.x or Mozilla); because it is consistent,
but also because I code HTML in the editor of my choice, and it's a pain
to do two copies. Yeah, AOL users mostly won't do that, but is overloading
"Copy" to do something inconsistent for text/unicode to save one context menu
item really easier for the less-experienced, who (other things being equal)
are more likely to want the UI as consistent as possible?

And yeah, this bug didn't originally refer to the 4xp "Copy Link Location" item,
so your patch could be considered to address the original RFE, but I'm sure I'm 
not the only one who subconsciously mapped (from the summary) '"copy URL" 
option' to '"Copy Link Location" item' (mapping the reporter's nostandard name  
for the context menu item desired for copying the URL onto the 4xp and 
Mozilla-consistent name for the item) and assumed that the RFE was for the 
latter -- especially since the reporter did ask for a "Copy URL" item, not a
"Copy" item that sometimes does that function -- so I hope you can understand 
the confusion attendant on throwing away a patch establishing a "Copy Link 
Location" item and calling a RFE for a "copy URL" item fixed. 

If you are adamant about doing that, I would *strongly* suggest changing the 
summary to something like
  "allow copying URL on right-clicking bookmark in manage bookmarks window"
to get rid of the confusion for everyone who would make the same mapping on 
reading the summary and initial comment.

Comment 37

[Claudius Gayle]

VERIFIED Fixed with 20010531 builds