Closed
Bug 21487
Opened 26 years ago
Closed 25 years ago
Copy link location copies garbage
Categories
(Core Graveyard :: Tracking, defect, P3)
Tracking
(Not tracked)
VERIFIED
FIXED
M13
People
(Reporter: andyelf, Assigned: mikepinkerton)
References
Details
(Whiteboard: fix in hand, testing, waiting for review from akkana)
Overview Description: When copying a link location (right-click on a link in a
browser) trailing garbage is also copied into a clipboard.
Steps to Reproduce:
1) Go to any page with links
2) Rigth-click on any link
3) Select 'Copy
link location'
4) Go to your favorite text editor and paste content of a clipboard -OR- Try
pasting just copied URL into location URL of Netscape/Mozilla/any other browser
Actual Results:
At the end of an URL there are some garbage characters, just like so:
http://bugzilla.mozilla.org/bug_status.html#rep_platformkH ´oHCÔmË)hiÔôÍ1@
(As you may guess, this is a copy of a link location from a 'Platform' link on
'Enter Bug' page of bugzilla)
Expected Results:
Guess :)
Build Date & Platform Bug Found:
SeaMonkey nightly build 1999120608
Platform: Debian GNU/Linux 2.1 with 2.2.12 kernel on a PPro-200
The same has been the same has been the case with SeaMonkey 1999112008 on the
same platform
Additional Builds and Platforms Tested On:
SeaMonkey 1999112008, same platform, same result
Additional Information:
Updated•26 years ago
|
Assignee: chofmann → beppe
Comment 1•26 years ago
|
||
beppe or trudelle?
Updated•26 years ago
|
Assignee: beppe → buster
Target Milestone: M13
Comment 2•26 years ago
|
||
it's actually goes to buster
Updated•26 years ago
|
QA Contact: leger → elig
Comment 5•26 years ago
|
||
Copy issue; QA Assigning to self.
Comment 6•26 years ago
|
||
I glanced at this a little to see if I could help ...
copyLink calls this.copyToClipboard( this.linkURL(), and at this point, linkURL
is fine.
copyToClipboard does, among other things, this:
transferable.addDataFlavor( "text/plain" );
// Create wrapper for text.
var data = createInstance( "component://netscape/supports-string",
"nsISupportsString" );
data.data = text ;
transferable.setTransferData( "text/plain", data, text.length * 2 );
// Put on clipboard.
clipboard.setData( transferable, null );
Why is it specifying double the length when it's only using text/plain? It
should either use text/unicode, or use text.length instead of text.length * 2.
Or, more likely, both: the former doesn't work for me if I then request the
selection as plain text, but the latter may not work on non-English systems.
Sdagley seems to be the owner of this code -- CCing him, and Naoki and Frank in
the hope that they might comment on the text vs. unicode issue (are URLs always
8-bit, or can they be more?) as well as myself and the clipboard owner.
Comment 7•26 years ago
|
||
I glanced at this a little to see if I could help ...
copyLink calls this.copyToClipboard( this.linkURL(), and at this point, linkURL
is fine.
copyToClipboard does, among other things, this:
transferable.addDataFlavor( "text/plain" );
// Create wrapper for text.
var data = createInstance( "component://netscape/supports-string",
"nsISupportsString" );
data.data = text ;
transferable.setTransferData( "text/plain", data, text.length * 2 );
// Put on clipboard.
clipboard.setData( transferable, null );
Why is it specifying double the length when it's only using text/plain? It
should either use text/unicode, or use text.length instead of text.length * 2.
Or, more likely, both: the former doesn't work for me if I then request the
selection as plain text, but the latter may not work on non-English systems.
Sdagley seems to be the owner of this code -- CCing him, and Naoki and Frank in
the hope that they might comment on the text vs. unicode issue (are URLs always
8-bit, or can they be more?) as well as myself and the clipboard owner.
Comment 8•26 years ago
|
||
URL may be in any charset (e.g., Shift_JIS) with escape. If the URL string is
internaly passed around without unescape then text/plain is fine. If we unescape
then we want to use text/unicode and we need charset conversion (from platform
charset to unicode, see nsIPlatformCharset.h).
Comment 10•26 years ago
|
||
akkana, thanks for the great analysis.
assigning to pinkerton, who I think owns clipboard today. Pink, if you aren't
the right assignee, can you please pass this off to the right person in your
group? Maybe sdagley?
Assignee | ||
Comment 11•25 years ago
|
||
Maybe i don't understand, but why is this a clipboard problem and not a usage
problem?
Assignee | ||
Updated•25 years ago
|
Status: NEW → ASSIGNED
Assignee | ||
Comment 12•25 years ago
|
||
I totall admit my ignorance about encodings, can someone explain our strategy
about encoded text/plain strings? If they are single-byte data with no embedded
nulls, then length is |text.length|, not |text.length*2| regardless of the
encoding, right? Or is this the one big mistake that everyone makes who doesn't
understand i18n? ;)
Is there a good doc to learn about all this stuff? I hate to keep asking the same
dumb questions over and over again.
Comment 13•25 years ago
|
||
Yes, you're right, |text.length|, not |text.length*2|. As the length is not used
for the character counts but for the byte length.
About books, how about,
Developing International Software for Windows 95 and Windows NT - Nadine Kano or
CJKV Information Processing - Ken Lunde
?
Assignee | ||
Comment 14•25 years ago
|
||
ok, so this isn't my bug. who should it go to?
Comment 15•25 years ago
|
||
I thought the current code does |text.length*2| instead of |text.length|, that
needs change, right?
Assignee | ||
Updated•25 years ago
|
Whiteboard: fix in hand, testing, waiting for review from akkana
Assignee | ||
Updated•25 years ago
|
Status: ASSIGNED → RESOLVED
Closed: 25 years ago
Resolution: --- → FIXED
Assignee | ||
Comment 16•25 years ago
|
||
i think this is fixed (i checked in a fix to the problems described) but i can't
actually dupe the bug on mac/windows and my linux box is dead. feel free to
reopen if it really isn't fixed.
Updated•25 years ago
|
Status: RESOLVED → VERIFIED
Comment 17•25 years ago
|
||
This appears fixed using the 2000011110 build on RH 6.0 Linux (also checked
2000011108 Mac OS and 2000011108 Win32).
---
andyelf, might you be open to giving this a quick check, and re-opening it if
you can still reproduce it? Thanks!
Reporter | ||
Comment 18•25 years ago
|
||
Confirm, works fine as of 2000011212 nightly build.
Updated•9 years ago
|
Product: Core → Core Graveyard
You need to log in
before you can comment on or make changes to this bug.
Description
•