Bug 31578 – [Chromium] Handle the prepended charset meta tag in the clipboard properly so that CnP works correctly

• Status: RESOLVED
• Resolution: FIXED
• Component: Platform

[Kinuko Yasuda]

We always prepend a special meta tag<meta charset='utf-8'> to the clipboard HTML for Chromium/Mac due to issue 27262, but this can break copy-and-paste behavior when the selected HTML starts with interchange breaklines/spaces.   It makes many layout tests that involve copy-and-paste fail on Mac (crbug.com/16823).
To avoid this we'll need to do either one of: 1) insert the meta tag more intelligently (e.g. put it right before text begins) or  2) handle or remove the meta tags properly after reading the clipboard HTML and before (or while) processing it.

One of the easiest fix would be somehow mark the meta tag with distinguishable name/identifier (like other interchange special markups do with class) and remove it in paste() if it exists.

[Kinuko Yasuda]

Created attachment 43348 [details]
Strip the special meta tag at the beginning of the copied HTML

[Kinuko Yasuda]

Hi Avi, can you take a look at the patch?  It's related to https://bugs.webkit.org/show_bug.cgi?id=27262 and http://crbug.com/11957.   Thanks,

[Avi Drissman]

If you've verified that copy/paste into, say, TextEdit works fine with the extra id, this looks great to me. I don't have review privs for WebKit, though, so I can't approve it.

[Kinuko Yasuda]

(In reply to comment #3)
> If you've verified that copy/paste into, say, TextEdit works fine with the
> extra id, this looks great to me. I don't have review privs for WebKit, though,
> so I can't approve it.

Thanks for taking a look at it, yes I've verified that copy/paste into TextEdit works fine with this change.  I'll wait for someone who has the priv to review it.

[Dimitri Glazkov (Google)]

Comment on attachment 43348 [details]
Strip the special meta tag at the beginning of the copied HTML

Needs a ChangeLog.

> +    m_dataObject->textHtml = String("<meta charset='utf-8' id='chromium-interchange-charset'>") + m_dataObject->textHtml;

should this be "chromium-" or "webkit-". Nitpicking, I know -- not a big deal either way :)

> +        DEFINE_STATIC_LOCAL(const String, forceUtf8String, ("<meta charset='utf-8' id='chromium-interchange-charset'>"));
> +        if (markup.startsWith(forceUtf8String)) {
> +          markup = markup.substring(forceUtf8String.length());
> +        }

No braces for one-line condition statements.

[Kinuko Yasuda]

Created attachment 43399 [details]
Strip the special meta tag at the beginning of the copied HTML

[Kinuko Yasuda]

Created attachment 43400 [details]
Strip the special meta tag at the beginning of the copied HTML

[Kinuko Yasuda]

Thanks for reviewing,

(In reply to comment #5)
> (From update of attachment 43348 [details])
> Needs a ChangeLog.
> No braces for one-line condition statements.

Updated.
 
> should this be "chromium-" or "webkit-". Nitpicking, I know -- not a big deal
> either way :)

Hmm, as the change is in WebKit code I've renamed it "webkit-".

[Eric Seidel (no email)]

How does Mac WebKit deal with this?

[Avi Drissman]

(In reply to comment #9)
> How does Mac WebKit deal with this?

Its data exchange format isn't html but webarchive, where you can specify the encoding for the HTML separately from the HTML itself.

[Eric Seidel (no email)]

Comment on attachment 43400 [details]
Strip the special meta tag at the beginning of the copied HTML

OK.  I guess my next question would be what FF Mac does.    BUt this is certainly no "worse" than before.

[WebKit Commit Bot]

Comment on attachment 43400 [details]
Strip the special meta tag at the beginning of the copied HTML

Clearing flags on attachment: 43400

Committed r51426: <http://trac.webkit.org/changeset/51426>

[WebKit Commit Bot]

All reviewed patches have been landed.  Closing bug.