Use explicit WebString <-> string conversion methods for notifications

Use explicit WebString <-> string conversion methods for notifications

As we're deprecating implicit conversions for WebString <-> string16
replace them with explicit methods. (See crbug.com/667131 for more
details)

BUG=667131
Review-Url: https://codereview.chromium.org/2613003002
Cr-Commit-Position: refs/heads/master@{#444273}
Committed: https://chromium.googlesource.com/chromium/src/+/c7f1bf8730353fab4a13f5173b282315ebbe11ba

[kinuko, 2017-01-05 05:32:31]

The CQ bit was checked by kinuko@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-05 05:32:49]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[kinuko, 2017-01-05 05:32:58]

Description was changed from

==========
Use explicit WebString <-> string conversion methods for notifications

As we're deprecating implicit conversions for WebString <-> string16
replace them with explicit methods. (See crbug.com/667131 for more
details)

BUG=667131
==========

to

==========
Use explicit WebString <-> string conversion methods for notifications

As we're deprecating implicit conversions for WebString <-> string16
replace them with explicit methods. (See crbug.com/667131 for more
details)

BUG=667131
==========

[kinuko, 2017-01-05 05:32:58]

kinuko@chromium.org changed reviewers:
+ peter@chromium.org

[kinuko, 2017-01-05 06:01:19]

Hi Peter, can you take a look?

The change's mostly mechanical (i.e. uses fromUTF16() and utf16() instead of
implicit conversions) but also replaces base::UTF16ToUTF8(webString) with
webString.utf8(), which could slightly change the output string if
unpaired/invalid surrogates are found in the given string.  More specifically,
UTF16ToUTF8 changes unpaired surrogates with 0xFFFD, while the latter performs
lenient conversion (basically ignores errors).  If this does look dangerous to
you we could fallback to use UTF16ToUTF8(webString.utf16()) instead of
webString.utf8().

[commit-bot: I haz the power, 2017-01-05 07:32:17]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-05 07:32:18]

Dry run: Try jobs failed on following builders:
  linux_chromium_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[Peter Beverloo, 2017-01-05 14:50:47]

lgtm % comment, as I may be wrong

As I understand it, the difference between a DOMString and an USVString is that
the former replaces invalid code points with 0xFFFD, whereas the latter doesn't
care.

The affected values in this CL all originate from DOMStrings, so I think we'll
need UTF16ToUTF8(webString.utf16()) to maintain the correct behaviour?

[kinuko, 2017-01-17 14:51:58]

The CQ bit was checked by kinuko@chromium.org to run a CQ dry run

[commit-bot: I haz the power, 2017-01-17 14:52:10]

Dry run: CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[kinuko, 2017-01-17 14:54:00]

On 2017/01/05 14:50:47, Peter Beverloo (OOO- Jan 19th) wrote:
> lgtm % comment, as I may be wrong
> 
> As I understand it, the difference between a DOMString and an USVString is
that
> the former replaces invalid code points with 0xFFFD, whereas the latter
doesn't
> care.
> 
> The affected values in this CL all originate from DOMStrings, so I think we'll
> need UTF16ToUTF8(webString.utf16()) to maintain the correct behaviour?

Ok, I made WebString::utf8() to take additional parameter for UTF8 conversion
mode so that it can do the same as UTF16ToUTF8.  The parameter name (i.e.
WebString::UTF8ConversionMode::kStrictReplacingErrorsWithFFFD) is not pretty but
could be still slightly more efficient as it doesn't create temporary utf-16
string / if the given string is already utf-8.

[commit-bot: I haz the power, 2017-01-17 15:04:06]

The CQ bit was unchecked by commit-bot@chromium.org

[commit-bot: I haz the power, 2017-01-17 15:04:07]

Dry run: Try jobs failed on following builders:
  linux_chromium_chromeos_rel_ng on master.tryserver.chromium.linux (JOB_FAILED,
http://build.chromium.org/p/tryserver.chromium.linux/builders/linux_chromium_...)

[kinuko, 2017-01-18 03:05:07]

The CQ bit was checked by kinuko@chromium.org

[kinuko, 2017-01-18 03:05:08]

The patchset sent to the CQ was uploaded after l-g-t-m from peter@chromium.org
Link to the patchset: https://codereview.chromium.org/2613003002/#ps60001
(title: "build fix")

[commit-bot: I haz the power, 2017-01-18 03:05:33]

CQ is trying da patch. Follow status at
 
https://chromium-cq-status.appspot.com/v2/patch-status/codereview.chromium.or...

[commit-bot: I haz the power, 2017-01-18 04:30:23]

CQ is committing da patch.

Bot data: {"patchset_id": 60001, "attempt_start_ts": 1484708707849300,
"parent_rev": "6d5cb27adaa84acccadd7880f1a94cb635ebac7c", "commit_rev":
"c7f1bf8730353fab4a13f5173b282315ebbe11ba"}

[commit-bot: I haz the power, 2017-01-18 04:30:55]

Description was changed from

==========
Use explicit WebString <-> string conversion methods for notifications

As we're deprecating implicit conversions for WebString <-> string16
replace them with explicit methods. (See crbug.com/667131 for more
details)

BUG=667131
==========

to

==========
Use explicit WebString <-> string conversion methods for notifications

As we're deprecating implicit conversions for WebString <-> string16
replace them with explicit methods. (See crbug.com/667131 for more
details)

BUG=667131

Review-Url: https://codereview.chromium.org/2613003002
Cr-Commit-Position: refs/heads/master@{#444273}
Committed:
https://chromium.googlesource.com/chromium/src/+/c7f1bf8730353fab4a13f5173b28...
==========

[commit-bot: I haz the power, 2017-01-18 04:30:56]

Committed patchset #4 (id:60001) as
https://chromium.googlesource.com/chromium/src/+/c7f1bf8730353fab4a13f5173b28...