Bug 55270 - [Qt] HTML 5 drag and drop uses incorrect text encoding
Summary: [Qt] HTML 5 drag and drop uses incorrect text encoding
Status: RESOLVED WORKSFORME
Alias: None
Product: WebKit
Classification: Unclassified
Component: WebKit Misc. (show other bugs)
Version: 528+ (Nightly build)
Hardware: Mac OS X 10.6
: P2 Normal
Assignee: Nobody
URL:
Keywords: Qt, QtTriaged
Depends on:
Blocks:
 
Reported: 2011-02-25 15:13 PST by Brian Ellis
Modified: 2011-03-02 06:31 PST (History)
3 users (show)

See Also:


Attachments
Reproduction case for this bug. (751 bytes, text/html)
2011-02-27 17:07 PST, Brian Ellis
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Brian Ellis 2011-02-25 15:13:04 PST
Affected Platforms:
Mac OS X 10.6 (at least -- haven't tested on other platforms).

Reproduction:
Write the following JavaScript code in an element's onDragBegin event handler:

  evt.effectAllowed = 'copy';
  evt.dataTransfer.setData('text/plain', 'Hello, world!');

Render the element in a QWebView.

Now, drag the element into another application (like a text editor).  When dropped, the single character "H" will be displayed in the text editor.

Drag the element again, this time into a QLineEdit within the same application.  When dropped, the string "H e l l o ,   w o r l d !" will be displayed in the QLineEdit.

Cause:
The string is encoded in UTF-16 (likely because JavaScript encodes all strings as UTF-16), but the pasteboard is expecting UTF-8.  QtWebKit does not seem to perform the conversion when the drag data is copied to the pasteboard, so the net effect is that (for plain ASCII text like "Hello, world!") the data is interspersed with NULL bytes.  This causes most implementations to truncate after the first character; within the same application, though, the length information is preserved, and so the NULLs are rendered as spaces.

Workaround:
You can partially work around the bug for within-application drops by manually reinterpreting the data as UTF-16, like so:

  QByteArray text = mimeData->data("text/plain");
  const char* utf16 = text.constData();
  QString real_text = QString::fromUtf16(reinterpret_cast<const ushort*>(utf16), text.length() / 2);

Suggested Fix:
Convert strings coming from JavaScript to UTF-8 before copying them to the pasteboard.
Comment 1 Benjamin Poulain 2011-02-27 07:03:16 PST
Would you mind attaching the HTML file of your test case so this bug report is complete?
Comment 2 Brian Ellis 2011-02-27 17:07:43 PST
Created attachment 84004 [details]
Reproduction case for this bug.

Attached.
Comment 3 Aparna Nandyal 2011-03-01 11:34:25 PST
Can you please confirm if the problem seen is infact on the nightly build or an older QtWebKit that shipped with Qt.

I am able to see the problem on the older release of QtWebKit shipped with 4.7.0 but not with the code in the trunk.
Comment 4 Benjamin Poulain 2011-03-02 06:31:40 PST
(In reply to comment #3)
> I am able to see the problem on the older release of QtWebKit shipped with 4.7.0 but not with the code in the trunk.

I second that. I just tested on Mac and I don't have any problem on trunk.