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)
Tracking
(Not tracked)
RESOLVED
EXPIRED
Future
People
(Reporter: bugzilla, Assigned: bbaetz)
References
Details
(Whiteboard: [adt3])
Attachments
(2 files, 1 obsolete file)
955 bytes,
patch
|
Details | Diff | Splinter Review | |
810 bytes,
patch
|
Details | Diff | Splinter Review |
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
Assignee | ||
Comment 1•23 years ago
|
||
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
Assignee | ||
Comment 3•23 years ago
|
||
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
Assignee | ||
Comment 4•23 years ago
|
||
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
I have an idea to fix this bug. Just create a function copyLink in nsContextMenu.js. I will paste a patch later.
Assignee | ||
Comment 10•23 years ago
|
||
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)
Comment 11•23 years ago
|
||
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.
Comment 12•23 years ago
|
||
*** Bug 117615 has been marked as a duplicate of this bug. ***
Assignee | ||
Comment 13•23 years ago
|
||
*** Bug 117176 has been marked as a duplicate of this bug. ***
Comment 14•23 years ago
|
||
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.
Assignee | ||
Comment 15•23 years ago
|
||
*** Bug 117176 has been marked as a duplicate of this bug. ***
Comment 16•23 years ago
|
||
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.
Comment 17•23 years ago
|
||
Can someone review the patch please?
Assignee | ||
Updated•23 years ago
|
Attachment #61068 -
Attachment mime type: text/plain → text/html
Assignee | ||
Comment 18•23 years ago
|
||
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
Assignee | ||
Comment 19•22 years ago
|
||
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
Comment 20•22 years ago
|
||
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
Comment 21•22 years ago
|
||
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.
Comment 22•22 years ago
|
||
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+
Reporter | ||
Comment 24•20 years ago
|
||
Comment on attachment 61068 [details] Test case for this bug marking obsolete, as per comment#6
Attachment #61068 -
Attachment is obsolete: true
Reporter | ||
Comment 25•20 years ago
|
||
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?
Updated•20 years ago
|
Product: Core → Mozilla Application Suite
Comment 26•15 years ago
|
||
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
Comment 27•14 years ago
|
||
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.
Description
•