Replace many [TreatReturnedNullStringAs=Null] with nullable DOMString

Replace many [TreatReturnedNullStringAs=Null] with nullable DOMString

In IDL files, the attribute declarations

  [TreatReturnedNullStringAs=Null] readonly attribute DOMString X;
  [TreatReturnedNullStringAs=Null, TreatNullAs=NullString] attribute DOMString X;

can now be changed into

  readonly attribute DOMString? X;
  attribute DOMString? X;

without changing behavior or generated code, so do that.

Similarly for methods, the declaration

  [TreatReturnedNullStringAs=Null] DOMString f();

can be changed into

  DOMString? f();

without changing behavior or generated code, so do that too.

Committed: https://src.chromium.org/viewvc/blink?view=rev&revision=177302

[Jens Widell, 2014-07-01 10:53:13]

PTAL

There are some [TreatReturnedNullStringAs=Null] left that we can remove, but
that lead to minor CG changes or require some minor fixes in the scripts, so I
left them for follow-ups.

Somewhat big CL, but no changes to generated code at all.

[haraken, 2014-07-01 11:16:03]

LGTM

https://codereview.chromium.org/361883004/diff/1/Source/core/frame/Window.idl
File Source/core/frame/Window.idl (right):

https://codereview.chromium.org/361883004/diff/1/Source/core/frame/Window.idl...
Source/core/frame/Window.idl:73: DOMString? prompt(optional DOMString message =
null,

Just to help me understand: How did we decide to write this?

  optional DOMString message = null

or

  optional DOMString? message = null

?

[Jens Widell, 2014-07-01 11:21:39]

On 2014/07/01 11:16:03, haraken wrote:
> LGTM
> 
> https://codereview.chromium.org/361883004/diff/1/Source/core/frame/Window.idl
> File Source/core/frame/Window.idl (right):
> 
>
https://codereview.chromium.org/361883004/diff/1/Source/core/frame/Window.idl...
> Source/core/frame/Window.idl:73: DOMString? prompt(optional DOMString message
=
> null,
> 
> Just to help me understand: How did we decide to write this?
> 
>   optional DOMString message = null
> 
> or
> 
>   optional DOMString? message = null
> 
> ?

In this particular case, the spec says the arguments should default to empty
strings (and not be nullable,) which is what we should do.

In the general case, this type of string argument should either have proper
default value, have no default (whichever way we choose to represent that) or be
nullable. Mostly depending on what the relevant spec actually says. Having a
non-nullable string argument default to null is just wrong.

[Jens Widell, 2014-07-01 11:22:58]

On 2014/07/01 11:21:39, Jens Lindström wrote:
> On 2014/07/01 11:16:03, haraken wrote:
> > Just to help me understand: How did we decide to write this?
> In the general case,

And also, I don't think we've decided completely what to do. We shouldn't do
what we do today, but exactly what we should replace it with in every instance
is unknown to me, at least. :-)

[haraken, 2014-07-01 11:42:35]

On 2014/07/01 11:22:58, Jens Lindström wrote:
> On 2014/07/01 11:21:39, Jens Lindström wrote:
> > On 2014/07/01 11:16:03, haraken wrote:
> > > Just to help me understand: How did we decide to write this?
> > In the general case,
> 
> And also, I don't think we've decided completely what to do. We shouldn't do
> what we do today, but exactly what we should replace it with in every instance
> is unknown to me, at least. :-)

Makes sense. I'm fine as long as we get to a consistent state in the end :)

[Jens Widell, 2014-07-01 11:43:07]

The CQ bit was checked by jl@opera.com

[commit-bot: I haz the power, 2014-07-01 11:44:19]

CQ is trying da patch. Follow status at
 https://chromium-status.appspot.com/cq/jl@opera.com/361883004/1

[commit-bot: I haz the power, 2014-07-01 12:49:53]

Change committed as 177302