Bug 235402 – Disable fallback path to WebRTC platform sockets

• Component: WebRTC
• Status: RESOLVED FIXED

[youenn fablet]

Disable fallback path to WebRC platform sockets

[youenn fablet]

Created attachment 449571 [details]
Patch

[Radar WebKit Bug Importer]

<rdar://problem/87829207>

[EWS]

Committed r288296 (246218@main): <https://commits.webkit.org/246218@main>

All reviewed patches have been landed. Closing bug and clearing flags on attachment 449571 [details].

[Geoffrey Garen]

Comment on attachment 449571 [details]
Patch

View in context: https://bugs.webkit.org/attachment.cgi?id=449571&action=review

> Source/WebKit/ChangeLog:10
> +        We should not fallback to the legacy WebRTC socket code path in Cocoa ports.
> +        Instead, if we cannot create the corresponding sockets (in case of ssltcp candidates for instance),
> +        we mark the socket as closed.

What's the expected outcome when we mark the socket as closed, and why is it an improvement?

[youenn fablet]

(In reply to Geoffrey Garen from comment #4)
> Comment on attachment 449571 [details]
> Patch
> 
> View in context:
> https://bugs.webkit.org/attachment.cgi?id=449571&action=review
> 
> > Source/WebKit/ChangeLog:10
> > +        We should not fallback to the legacy WebRTC socket code path in Cocoa ports.
> > +        Instead, if we cannot create the corresponding sockets (in case of ssltcp candidates for instance),
> > +        we mark the socket as closed.
> 
> What's the expected outcome when we mark the socket as closed, and why is it
> an improvement?

The improvement is mostly to not go on the legacy code path (so we return early whenever m_platformTCPSocketsEnabled is true).
Closing the socket is notifying the WebProcess that this socket cannot be used, which is better for memory management.