Closed Bug 103827 Opened 23 years ago Closed 14 years ago

Can't 'Copy Link Address' from a file::/// listing

Categories

(SeaMonkey :: UI Design, defect, P3)

Sun
SunOS

Tracking

(Not tracked)

RESOLVED EXPIRED
Future

People

(Reporter: bugzilla, Assigned: bbaetz)

References

Details

(Whiteboard: [adt3])

Attachments

(2 files, 1 obsolete file)

From Bugzilla Helper:
User-Agent: Mozilla/5.0 (X11; U; SunOS sun4u; en-US; rv:0.9.5+) Gecko/20011008
BuildID:    20011008

Right clicking on an entry in a directory listing generated from a file:/// URL
gives you the option to 'Copy Link Address', but it doesn't work.

The following error appears in the terminal:

>> An error occurred executing the cmd_copyLink command

Normal cut-and-paste operations work fine, and Copying a link from an html page
works fine.

Reproducible: Always
Steps to Reproduce:
1.Type 'file::///' in the URL bar
2.Right click on an entry to get the context menu
3.Select 'Copy Link Address'
4) Try pasting the location somewhere

Actual Results:  The clipboard has not changed

Expected Results:  The file:/// location URL should be in the X clipboard for
pasting
Confirming, and ->me

This whole interface needs to be rewritten; in the meantime, file://// will work
in the html mode sometime soon, I hope.
Assignee: pchen → bbaetz
Status: UNCONFIRMED → NEW
Ever confirmed: true
xul viewer rewrite -> 0.9.7
Target Milestone: --- → mozilla0.9.7
OK, so the httpdirindex stuff in nsContextMenu.js is really ugly. I should be
using an overlay instead, or something.

->0.9.9
Severity: normal → minor
Priority: -- → P3
Target Milestone: mozilla0.9.7 → mozilla0.9.9
OK, moving all XUL dirviewer bugs to post 1.0. I don't want to be doing this,
but there are only so many hours in the day. These will be taken earlier if
someone submits a patch, or I find time.
Target Milestone: mozilla0.9.9 → mozilla1.0.1
Attached file Test case for this bug (obsolete) —
Just same as the comments above.
Sorry, I have added the attachment in wrong place... :-P
I have an idea to fix this bug.
Just create a function copyLink in nsContextMenu.js.
I will paste a patch later.
Don't you need to copy it as a URL? Or does the clipboard service do that for 
youy (I'm not in a position to test atm)
Yes, I just do the same thing as copyEmail function.
I have tested it yet on my workstation (sun sparc with solaris 9 and windows
2000).I think it's no problem because copyEmail function always work.
*** Bug 117615 has been marked as a duplicate of this bug. ***
*** Bug 117176 has been marked as a duplicate of this bug. ***
This bug is about a right click menu function not working as designed. Bug
117176 is distinguishable in that its focus is on the fact that the mouse cannot
select any page content to copy to clipboard and therefore not a dupe.
*** Bug 117176 has been marked as a duplicate of this bug. ***
This bug is about a right click menu function not working as designed.

Bug 117176 is distinguishable in that its focus is on the fact that the mouse
cannot select any page content to copy to clipboard. On any normal HTML page,
any or all of the page can be selected and copied to the clipboard, such as when
the need to save the page content as a text file (bug 70045) arises. Bug 117176
is not a dupe.
Blocks: 117176
Can someone review the patch please?
Attachment #61068 - Attachment mime type: text/plain → text/html
Err, my comment didn't go through. /me kicks his proxy server

Anyway, what I was going to say was that I'm not sure about removing
cmd_copyLink, since I presume that that code has lots of special cases (the main
one being that it should copy as a link, not as plain text). The real solution
is to make the <tree> accept copying, or overridecopy from the context menu js
file. I'd have to see if that was possible, and how to do so, but I suspect this
may just work once outliner lands. It may not - this code may need its own
specific overlay instead.

I don't think your comment #11 is true - theres obviously a reason that this
code was done that way. I'll ask arround

See the routines arround
http://lxr.mozilla.org/seamonkey/source/dom/src/base/nsGlobalWindow.cpp#5029 for
where this support currently happens
Following the roadmap, 1.0.1 is a maintenance release, so pushing off features
(xul direviewer) to 1.1
Target Milestone: mozilla1.0.1 → mozilla1.1
Keywords: nsbeta1+
Keywords: nsbeta1
Whiteboard: [adt3]
Mass moving nsbeta1+/adt3 bugs assigned to Navigator team engineers out to
target milestone 1.0.1.  Please confine your attentions to driving down our list
of TM 1.0 bugs for beta.  Better to help, debug, or test one of them than fix
one of these.
Target Milestone: mozilla1.1alpha → mozilla1.0.1
Keywords: nsbeta1-
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Changing nsbeta1+ [adt3] bugs to nsbeta1- on behalf of the adt.  If you have any
questions about this, please email adt@netscape.com.  You can search for
"changing adt3 bugs" to quickly find and delete these bug mails.
Keywords: nsbeta1+
retargeting
Target Milestone: mozilla1.0.1 → Future
Comment on attachment 61068 [details]
Test case for this bug

marking obsolete, as per comment#6
Attachment #61068 - Attachment is obsolete: true
This bug seems to be fixed, at least on my Windows Mozilla 1.7.

Would people agree this can be resolved now, or do the proposed patches still
need reviewing/applying?
Product: Core → Mozilla Application Suite
This bug report is registered in the SeaMonkey product, but has been without a comment since the inception of the SeaMonkey project. This means that it was logged against the old Mozilla suite and we cannot determine that it's still valid for the current SeaMonkey suite. Because of this, we are setting it to an UNCONFIRMED state.

If you can confirm that this report still applies to current SeaMonkey 2.x nightly builds, please set it back to the NEW state along with a comment on how you reproduced it on what Build ID, or if it's an enhancement request, why it's still worth implementing and in what way.
If you can confirm that the report doesn't apply to current SeaMonkey 2.x nightly builds, please set it to the appropriate RESOLVED state (WORKSFORME, INVALID, WONTFIX, or similar).
If no action happens within the next few months, we move this bug report to an EXPIRED state.

Query tag for this change: mass-UNCONFIRM-20090614
Status: NEW → UNCONFIRMED
MASS-CHANGE:
This bug report is registered in the SeaMonkey product, but still has no comment since the inception of the SeaMonkey project 5 years ago.

Because of this, we're resolving the bug as EXPIRED.

If you still can reproduce the bug on SeaMonkey 2 or otherwise think it's still valid, please REOPEN it and if it is a platform or toolkit issue, move it to the according component.

Query tag for this change: EXPIRED-20100420
Status: UNCONFIRMED → RESOLVED
Closed: 14 years ago
Resolution: --- → EXPIRED
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: