Closed
Bug 437047
Opened 16 years ago
Closed 16 years ago
cannot paste data from other application if target is not text/plain or html
Categories
(Core :: Widget, defect)
Tracking
()
VERIFIED
FIXED
mozilla1.9.1a2
People
(Reporter: arno, Assigned: arno)
Details
Attachments
(3 files, 2 obsolete files)
2.41 KB,
patch
|
roc
:
review+
roc
:
superreview+
|
Details | Diff | Splinter Review |
1.73 KB,
text/plain
|
Details | |
2.31 KB,
application/javascript
|
Details |
Hi, I'm trying to paste data from another application. Foreign application is gtk. Data is gchar*, and target is a custom one. So, when trying to paste to mozilla, by calling clipboard.getData from javascript my data is packed in a two-bytes nsISupportsString (in nsPrimitiveHelpers::CreatePrimitiveForData). So, I can get the data from javascript by unpacking with a custom function. But problem is: if length of data is odd, I don't get the last byte. That's because in nsPrimitiveHelpers::CreatePrimitiveForData, primitive->SetData(Substring(start, start + (aDataLen / 2))); does not take the last character if length is odd. I'll attach a patch that seems to fix the problem. Unfortunately, I could not think of a test because when copying data from mozilla, it is internaly transformed into two-bytes nsISupportsString. So, I would need to run an external program to make a testcase.
same as bug 428096?
Assignee | ||
Comment 2•16 years ago
|
||
Oups, I believed I had attached a patch. Sorry for the delay then. No, it's not the same as bug 428096. problems arrives if you want to paste data to mozilla with a flavor gecko does not know of.
Assignee | ||
Comment 3•16 years ago
|
||
Comment 4•16 years ago
|
||
Arno, you should ask for review.
Assignee | ||
Updated•16 years ago
|
Attachment #332989 -
Flags: review?(joshmoz)
Attachment #332989 -
Flags: review?(joshmoz) → review?(ventnor.bugzilla)
Comment 5•16 years ago
|
||
Comment on attachment 332989 [details] [diff] [review] adds two extra bytes to data string if datalen is odd Whoa...xpwidgets? Definitely roc's forte, not mine.
Attachment #332989 -
Flags: superreview?(roc)
Attachment #332989 -
Flags: review?(ventnor.bugzilla)
Attachment #332989 -
Flags: review?(roc)
Doesn't this mean we read an uninitialized byte when aDataLen is odd?
Assignee | ||
Comment 7•16 years ago
|
||
yes, may be I should set last byte to null, but I read http://developer.mozilla.org/en/docs/XPCOM:Strings and did not found or understood how to do.
When aDataLen is odd you might need to copy data to a temporary buffer and append a null byte to that.
Assignee | ||
Comment 9•16 years ago
|
||
Assignee: nobody → arenevier
Attachment #332989 -
Attachment is obsolete: true
Status: NEW → ASSIGNED
Attachment #333536 -
Flags: review?(roc)
Attachment #332989 -
Flags: superreview?(roc)
Attachment #332989 -
Flags: review?(roc)
Assignee | ||
Comment 10•16 years ago
|
||
I don't known if it's better to use calloc, or malloc + setting last byte to null.
Use nsAutoArrayPtr here to avoid having to call free explicitly, and just set the last byte to zero. + const PRUnichar* start = (const PRUnichar*)buffer; Can you change these to reinterpret_cast<> while you're here? Thanks.
Assignee | ||
Comment 12•16 years ago
|
||
Attachment #333536 -
Attachment is obsolete: true
Attachment #334083 -
Flags: review?(roc)
Attachment #333536 -
Flags: review?(roc)
Attachment #334083 -
Flags: superreview+
Attachment #334083 -
Flags: review?(roc)
Attachment #334083 -
Flags: review+
Assignee | ||
Updated•16 years ago
|
Keywords: checkin-needed
Comment 13•16 years ago
|
||
Pushed to mozilla-central: https://hg.mozilla.org/mozilla-central/index.cgi/rev/357e923405af
Comment 14•16 years ago
|
||
Arno, can you verify the fix with an official nightly please? That would be helpful.
Target Milestone: --- → mozilla1.9.1a2
Version: unspecified → Trunk
Assignee | ||
Comment 15•16 years ago
|
||
seems to work fine with latest firefox nightly
Comment 16•16 years ago
|
||
Marking verified based on comment 15. Arno, is this Linux only or could it also happen on other platforms / OS?
Status: RESOLVED → VERIFIED
Assignee | ||
Comment 17•16 years ago
|
||
I suppose problem can be seen on other systems, but I'm really not sure.
Comment 18•16 years ago
|
||
Martijn, would it be good to have an automated test here? At least a simple testcase would be great so we could use it as Litmus test. With such a testcase we could also test the fix on all other systems.
Assignee | ||
Comment 19•16 years ago
|
||
problem is that you need to have an external program (to put stuff in the clipboard) to trigger that behaviour.
Comment 20•16 years ago
|
||
It would always be good to have an automated test for this. But I guess it might be very difficult to achieve this, like Arno said (I don't know this code at all). A litmus-test would be fine too.
Flags: in-testsuite?
Flags: in-litmus?
Assignee | ||
Comment 21•16 years ago
|
||
I don't know how that could be useful, but here is the code I use to put stuff in the clipboard. It uses gtk.
Assignee | ||
Comment 22•16 years ago
|
||
And here is the javascript snippet I use to read stuff from clipboard.
Assignee | ||
Updated•16 years ago
|
Attachment #335451 -
Attachment mime type: text/x-csrc → text/plain
You need to log in
before you can comment on or make changes to this bug.
Description
•