TreatReturnedNullStringAs=undefined removed from WebSocket.idl

TreatReturnedNullStringAs=undefined removed from WebSocket.idl

DOMWebSocket::m_subprotocol and ::m_extensions are initialized as
empty strings and are only updated in DOMWebSocket::didConnect(), where
the values ultimate come from WebSocketStream::GetSubProtocol() and
::GetExtensions() which are std::string in Chromium. These are both
documented as returning the empty string if no protocol/extensions
were negotiated, and std::string as no null state like WTF::String. In
other words, it's not possible for these to return null string, but
even if they did it would appropriate to convert that to empty strings
as opposed to undefined.

BUG=497982
R=philipj, haraken

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

[Habib Virji, 2015-06-11 09:07:14]

The CQ bit was checked by habib.virji@samsung.com to run a CQ dry run

[commit-bot: I haz the power, 2015-06-11 09:07:26]

Dry run: CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1175183004/1

[commit-bot: I haz the power, 2015-06-11 11:11:04]

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

[commit-bot: I haz the power, 2015-06-11 11:11:04]

Dry run: This issue passed the CQ dry run.

[philipj_slow, 2015-06-11 13:39:07]

LGTM. I looked into this case and updated the description with an explanation of
why this change is sound. Please do something similar for the other CLs as well,
as digging into these things will sometimes reveal unexpected things.

[tyoshino (SeeGerritForStatus), 2015-06-11 13:58:52]

lgtm

From spec side point of view: _Extensions In Use_ and _Subprotocol In Use_ may
become null but "Feedback from the protocol" changes the attributes only when
they're not null value.

I agree that given the analysis of the code, the spec requirements are met, and
even without TreatReturnedNullStringAs, they're met.

[Habib Virji, 2015-06-11 14:03:50]

On 2015/06/11 13:39:07, philipj wrote:
> LGTM. I looked into this case and updated the description with an explanation
of
> why this change is sound. Please do something similar for the other CLs as
well,
> as digging into these things will sometimes reveal unexpected things.

Thanks philips for the nice description. Will work on the
DataTransfer/XSLT/Document to come with the similar explanation.

[haraken, 2015-06-11 14:07:23]

LGTM

[Habib Virji, 2015-06-11 14:07:29]

The CQ bit was checked by habib.virji@samsung.com

[commit-bot: I haz the power, 2015-06-11 14:07:53]

CQ is trying da patch. Follow status at
 https://chromium-cq-status.appspot.com/patch-status/1175183004/1

[commit-bot: I haz the power, 2015-06-11 14:11:19]

Committed patchset #1 (id:1) as
https://src.chromium.org/viewvc/blink?view=rev&revision=196948