Closed Bug 80059 Opened 24 years ago Closed 22 years ago

Copy and Copy Link Location don't put anything to clipboard

Categories

(Core :: DOM: UI Events & Focus Handling, defect, P1)

Product:
Core
Component:
DOM: UI Events & Focus Handling
Type:
defect

Tracking

()

Status:
RESOLVED WORKSFORME

People

(Reporter: bugzilla3, Assigned: joki)

References

Details

(Keywords: regression, Whiteboard: critical for 0.9.1 [reviewed and super-reviewed patch in hand])

Attachments

(1 file)

add nsIClipboard to nsSetupRegistry.cpp
2.01 KB, patch
Details | Diff | Splinter Review 
I am seeing this on any html page.
Seen this on build 2001051004, Win98.
Keywords: regression
Summary: opy and Copy Link Location don't put anything to clipboard → Copy and Copy Link Location don't put anything to clipboard
QA Contact: sairuh → tpreston
I tested this build again and the results are more strange: copy works on the
win98 system now but on another system with win95 installed, context menus don't
work at all. 
Maybe these are OS issues non related to Mozilla or there was a previous crash I
didn't notice (that prevented susequent Mozilla sessions from working reliably).
I keep my bug open in case I am wrong and there is really a problem in the
application. I apologise for the annoyance.
Occurs in 20010512 Win98 also. If I could confirm the bug, I would.
ccing dr and gerv
Also seeing this with 2001051220 / Win98SE.
-> dr
Assignee: blakeross → dr
Status: UNCONFIRMED → NEW
Ever confirmed: true
Keywords: mozilla0.9.1, nsbeta1
Whiteboard: 0.9.1
*** Bug 80595 has been marked as a duplicate of this bug. ***
Could be a regression from xpcdom?
Blocks: 80656
*** Bug 80672 has been marked as a duplicate of this bug. ***
*** Bug 80656 has been marked as a duplicate of this bug. ***
see it on Win2K 2001051308
No longer blocks: 80656
2001051408 Linux worksforme, both the selection clipboard and the standard
clipboard. This seems to be non-XP. How odd.

Gerv
Alright, this bug report confuses me. Is it that you're unable to bring up a
context menu, or is it that you click "copy link" and it doesn't do anything?
On Windows build 2001051404, If I right click on a link, the context menu comes 
up but when I select copy link location, nothing is put in the clipboard
Terri: thanks for the clarification :) I'm wondering if it's just copying links
that's affected, or if the windows clipboard is messed up in general right
now... This worked for me just fine on windows, at least before my
nsIClipboardHelper landing. Well, that's one thing I have to look into, at
least... I have a feeling the |GetService| magic I tried to do didn't work
*quite* right.
Status: NEW → ASSIGNED
Component: XP Apps: GUI Features → XP Toolkit/Widgets
Priority: -- → P1
QA Contact: tpreston → jrgm
Target Milestone: --- → mozilla0.9.1
No, it seems that the clipboard code isn't messed up, when I select ordinary
text on the page, and press CTRl-C, on right-click on it and choose 'copy', to
goes to clipboard. However, if I either right click:
1. on an image and choose 'copy image location'
2. on an image and choose 'copy' (it isn't a link, but was it even implemented
before? I don't know)
3. on a mailto: link and choose 'copy e-mail address'
4. on any link and choose 'copy link location'
then nothing arrives in the clipboard (the clipboard still holds its previous
contents).
My build ID: 2001051420
My OS: Windows 98 SE Polish version
Additional data point which may become another bug later -

This bug WFM on Linux, but if I select an area, then right-click a link and do 
"Copy Link Location", the selection clipboard gets nuked with the link location. 
I'm pretty sure this is not the right behaviour.

Gerv
Gerv: I'm not positive that what you mention (copy link location copies to
selection clipboard) is a bug -- it did work that way before my changes. Do you
know some rules that I don't about what should be copied to the selection
clipboard and what shouldn't? Regardless, this is a topic of another bug, if you
choose to pursue the issue :)
Yep, fair enough. Counter-intuitive, but 4xp, so I'm not going to push it.

Gerv
Additional information (originally filed in bug 80672), may be of use:

Whenever I try to do Copy Link Location, no matter what kind of page or what
kind of link, I get the following in the debug console:

  An error occurred executing the cmd_copyLink command

The clipboard isn't totally broken, however, selecting a piece of text,
right-clicking and selecting Copy works fine.
this will probably mean more to dr than me, but if I dump out the full 
exception in globalOverlay.js (where the error message is coming from),
I get :

An error occurred executing the cmd_copyImageLocation command
[Exception... "Component returned failure code: 0x80040154 
 (NS_ERROR_FACTORY_NOT_REGISTERED) [nsIController.doCommand]"  
 nsresult: "0x80040154 (NS_ERROR_FACTORY_NOT_REGISTERED)"  
 location: "JS frame :: chrome://global/content/globalOverlay.js :: 
 goDoCommand :: line 72"  data: no]


*** Bug 81049 has been marked as a duplicate of this bug. ***
jrgm: *whoa*

From the look of that dump, it looks like something is wrong with the component
loader on Win98... I have to get my build on Win2K up to date to triage this
problem better.
I'm seeing this with NT4sp6a.
I'm seeing this with build 2001051504 Win98SE.

*** Bug 80534 has been marked as a duplicate of this bug. ***
It's dogfood! No way to put a link into clipboard.
I do not see this on 2001051704 installer Win32 build (WindowsME).
Retraction: Yes, I do see this now. Ignore my previous message. 
*Okay, People* I'm glad everybody sees this. I believe you. Y'all simmer down now.
Keywords: nsdogfood
Okay, there's some trouble with the widget factory. The js error jrgm was seeing
is coming from PresShell::DoCopyLinkLocation. The following code fails:

nsCOMPtr<nsIClipboardHelper>
  clipboard(do_GetService("@mozilla.org/widget/clipboardhelper;1", &rv));
NS_ENSURE_SUCCESS(rv, rv);

The result value here, as jrgm saw, is NS_ERROR_FACTORY_NOT_REGISTERED.

When I created nsIClipboardHelper, I patched all the widget factories, including
nsWinWidgetFactory -- I need to find out why my patches to all the factories
worked fine *except* this one. But this definitely seems to be where things are
going awry.
Cleaning up the cc list a bit to avoid further spammage. Adding rods and saari
for help with the widget factories.
Hadn't seen it til build 2001051720, seeing it now on W95B. 

Aside:  Who's idea was it to get rid of the handy 'mozilla' links from status
bar area?  Was a -great- way to get here.
*** Bug 81655 has been marked as a duplicate of this bug. ***
Whiteboard: 0.9.1 → critical for 0.9.1
Pink says this happens on Mac too. Fortunately, Pink also told me exactly how 
to fix this. God bless Pink. Patch coming right up.
Severity: normal → critical
OS: Windows 98 → All
Hardware: PC → All
This should do it, afaict. Tested on windows, but can somebody please test on
mac? Looking for r=, sr=. Thanks.
Keywords: approval, patch, review
Whiteboard: critical for 0.9.1 → critical for 0.9.1 [patch in hand, needs testing and review]
r=pink. this fixes it on mac....one thing: do you really need to put your name in 
the contributor section? ;)

Dan, dude, I must say I *strongly* object to your changes to the contributor
comment section, both to removing pp@ludusdesign.com (which we've discussed
before) and to adding your name as a contributor simply for typing down a fix
that according to your earlier comment pinkerton gave you, I'm sorry, but you
should only add yourself as a contributor if you've truly made some really
significant contributions, this change is IMO nowhere close to that.

If you leave the contributor field unchanged you may check in with sr=jst.
Johnny: Pierre Phaneuf's name is plastered on hundreds of files in the codebase
for having been the one to check in a simple search-and-replace for a facility
that came on-line in the early days of XPCOM. He gave explicit permission on IRC
a couple months ago, given the challenge to actually find a line of Mozilla code
blamed on him by LXR, to remove his name from files he appears as a contributor in.

I've been adding my names to files mostly as a note to myself that I understand
the file, under the impression that that was in the spirit of the MPL. My
contribution to this file is hardly significant, but it's useful to myself and
to others looking for info, to know that I have at least a vague understanding
of what the file is doing. Pierre can't make this claim, nor does he want to --
he said he still gets unwanted email asking about parts of certain files.

I don't think either adding myself or removing Pierre is inappropriate.

I'll check in without the changes to the contributors, since I don't want this
discussion to hold up the fix, but we should probably take this off-line.
Whiteboard: critical for 0.9.1 [patch in hand, needs testing and review] → critical for 0.9.1 [reviewed and super-reviewed patch in hand]
I know what Pierre did and that his name is all over the code base, but what's
done is done, I don't wanto start arguing about that. Had I known that you had
discussed this with Pierre and that he was ok with you removing him as a
contributor to this file then I wouldn't have objected to that, so in the future
please be clear about that in your comments in the bugs where you attach patches
where names are removed from the contributor section of a file.

I don't know if adding yourself as a contributor to a file for making
non-significant changes to the file is in the spirit of the MPL or not, but I do
know that it's against common practice and I do know that other super reviewers
object to such practice in general, hyatt to name one. If everyone who has ever
touched a file in the repository would have added themselves to the contributor
section we'd end up with huge, meaningless and unmanageable contributor sections
in all our files, so I'm not encouraging such practice. CVS blame and the CVS
change logs shows you who has been touching the files so people can use that to
find people that are likely to know the code in question.
Fixed.
Status: ASSIGNED → RESOLVED
Closed: 24 years ago
Resolution: --- → FIXED
no longer seeing this problem on Win32 2001052204
WFM 2001052204 Win98. Take one down, pass it around...
That's nice and everything, but would somebody please mark the bug verified?
No, we want it still in the most frequent list for a few days.

Worksforme with build 2001052204 on Win98SE.
Verified w2k 2001052204
Status: RESOLVED → VERIFIED
*** Bug 80569 has been marked as a duplicate of this bug. ***
*** Bug 83275 has been marked as a duplicate of this bug. ***
In 1.0RC2, this bug is back. I see it with any links on all pages. Platform - Linux.
Status: VERIFIED → REOPENED
Resolution: FIXED → ---
->events.
Assignee: dr → joki
Status: REOPENED → NEW
Component: XP Toolkit/Widgets → Event Handling
QA Contact: jrgm → rakeshmishra
I'm seeing this problem on win95 and linux.
I see this behaviour on my Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.0rc2)
Gecko/20020514. 1.0rc1 was fine, though.
Correction to my previous comment:
'Copy' works ok, just 'Copy link location' fails.
I made comments #54 & #55. I just upgraded to rc3 and 'Copy Link Location' works
like a charm! Thanks, guys!!!
It does not work in Mozilla 1.0 rc2 too.
Keywords: mozilla1.1
Should we change the Target Milestone to some real value, since 0.9.1 was
released looong-looong ago?
Reseting target, Joki, please set any more relevant.
Target Milestone: mozilla0.9.1 → ---
Does not work for me.
Mozilla 1.0 Release Candidate 2
Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.0rc2) Gecko/20020510
QA Contact: rakeshmishra → trix
This works in current trunk builds and also in Mozilla 1.0.0.
Actually the only build where this appeared (after being marked WFM a long time
before) is 1.0rc2.

So please comment if this is still an issue with a current Mozilla build.
I'm going to resolve this bug if there is no response.
Mozilla/5.0 (X11; U; FreeBSD i386; en-US; rv:1.3b) Gecko/20030213
don't contain this bug. Works fine here.
->WFM
This was only a problem in Mozilla 1.0rc2 after already being resolved as WFM a
long time before. It works on branch, trunk and in 1.0.0.
Status: NEW → RESOLVED
Closed: 24 years ago → 22 years ago
Resolution: --- → WORKSFORME
Component: Event Handling → User events and focus handling
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: