Remove special handling for strings in var serialization.

Remove special handling for strings in var serialization.

Previously we had to have a lot of weird string handling because strings needed a PP_Module to be constructed, and because they had different methods for being created in the host and the plugin processes. We've removed all of these limitations, so now we can just delete the whole mess.

Committed: https://src.chromium.org/viewvc/chrome?view=rev&revision=120724

[brettw, 2012-02-06 04:16:38]

I saw your string optimization go by, which is great, but remembered I keep
meaning to remove the whole string mess. So you inspired me to do so when I had
a few minutes today.

It should be the same number of copies as your old code but -162 lines. Sorry to
make your patch obsolete, I didn't mean to step on your toes.

[dmichael (off chromium), 2012-02-06 17:07:28]

Ugh, yeah, I realized it was ripe for simplifying as soon as I started on
proxying array buffer, and was going to do basically the same thing today. You
beat me to it ;-)

FWIW, you can double-check with ppapi_perftests that this doesn't hurt
performance. I don't expect any surprises, but it might be worth running quickly
anyway.

LGTM

[commit-bot: I haz the power, 2012-02-06 17:55:32]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/brettw@chromium.org/9316123/1

[commit-bot: I haz the power, 2012-02-06 20:01:42]

Try job failure for 9316123-1 (retry) on mac_rel for step "browser_tests".
It's a second try, previously, steps "browser_tests, ui_tests" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[commit-bot: I haz the power, 2012-02-06 22:00:02]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/brettw@chromium.org/9316123/1

[commit-bot: I haz the power, 2012-02-07 01:48:35]

Try job failure for 9316123-1 (retry) (previous was lost) on mac_rel for steps
"browser_tests, ui_tests".
It's a second try, previously, step "browser_tests" failed.
http://build.chromium.org/p/tryserver.chromium/buildstatus?builder=mac_rel&nu...

[brettw, 2012-02-07 05:36:19]

> FWIW, you can double-check with ppapi_perftests that this doesn't hurt
> performance. I don't expect any surprises, but it might be worth running
quickly
> anyway.

I did Debug mode only (too lazy to compile in Release). Before it was 318, after
this patch it was 216, so I guess that's good!

[commit-bot: I haz the power, 2012-02-07 05:38:36]

CQ is trying da patch. Follow status at
https://chromium-status.appspot.com/cq/brettw@chromium.org/9316123/1

[commit-bot: I haz the power, 2012-02-07 05:38:40]

Can't apply patch for file ppapi/proxy/host_var_serialization_rules.cc.
While running patch -p1 --forward --force;
patching file ppapi/proxy/host_var_serialization_rules.cc
Hunk #1 FAILED at 24.
Hunk #2 FAILED at 83.
2 out of 2 hunks FAILED -- saving rejects to file
ppapi/proxy/host_var_serialization_rules.cc.rej

[dmichael (off chromium), 2012-02-07 16:35:30]

https://chromiumcodereview.appspot.com/9316123/diff/1/ppapi/proxy/serialized_...
File ppapi/proxy/serialized_var.cc (right):

https://chromiumcodereview.appspot.com/9316123/diff/1/ppapi/proxy/serialized_...
ppapi/proxy/serialized_var.cc:176: var_ =
StringVar::SwapValidatedUTF8StringIntoPPVar(&string_from_ipc);
It just occurred to me that we maybe should still do the extra UTF8 validation
on the browser side when we receive a string, since the plugin side of the proxy
is (going to be) untrusted, and downstream code probably assumes valid UTF8.

What do you think? :-/

[brettw, 2012-02-07 16:56:31]

https://chromiumcodereview.appspot.com/9316123/diff/1/ppapi/proxy/serialized_...
File ppapi/proxy/serialized_var.cc (right):

https://chromiumcodereview.appspot.com/9316123/diff/1/ppapi/proxy/serialized_...
ppapi/proxy/serialized_var.cc:176: var_ =
StringVar::SwapValidatedUTF8StringIntoPPVar(&string_from_ipc);
The validating we do is mostly because we wanted to force people to do the right
thing rather than having weird behaviors. I think we can skip this extra step.
Chrome's behavior for non-UTF-8 strings should be well-defined, and I'm not
particularly worried about security problems here.

[dmichael (off chromium), 2012-02-07 16:59:03]

lgtm