Currently we serialize the values using custom JSON implementation to serialize the values(see bug 32554 for more details on why we need that custom implementation). Using SerializedScriptValue would allow to get rid of that custom implementation and would work for both in-process and out-of-process front-end since SerializedScriptValue can be converted into a String or new JS object in specified ExecState.
Created attachment 48221 [details]
Comment on attachment 48221 [details]
I like this a lot!
> +PassRefPtr<SerializedScriptValue> serialize(ScriptState* scriptState, const ScriptValue& value)
> + return SerializedScriptValue::create(scriptState, value.jsValue());
Should this be defined in ScriptValue instead?
> +ScriptValue deserialize(ScriptState* scriptState, SerializedScriptValue* value)
> + return ScriptValue(value->deserialize(scriptState, scriptState->lexicalGlobalObject()));
> - var argsArray = InjectedScript.JSON.parse(args);
> + var argsArray = JSON.parse(args);
Overriding JSON would bring harm us here. I realize that parse is much more standard than stringify, but still. I'd suggest that you either inline copy of parse method here or simply use eval. This method is being called from the trusted source, it has only valid symbols, etc. r- for this.
Created attachment 48226 [details]
Addressed all the comments.
Comment on attachment 48226 [details]
Nit: I'd probably do a constructor instead of ScriptValue::deserialize.
(In reply to comment #4)
> (From update of attachment 48226 [details])
> Nit: I'd probably do a constructor instead of ScriptValue::deserialize.
Adding a constructor would still require a static method which would still require a static method that would enter the script state scope before deserializing value so I'd rather stick with this approach.
Committing to http://svn.webkit.org/repository/webkit/trunk ...