that is no any more in build 16299.19

same problem here

Performance yes, but TLS False start does not improve security, it does the opposite; Firefox Hardening Guide 2018

Disable TLS False Start

This is because it does not allow the client to fully complete its handshake before starting the actual session. There is more info here from the IETF: https://tools.ietf.org/html/rfc7918#section-4 (See section 5. Security Considerations)

TCP fast open will also reduce privacy for the server and client will store cookies that can be used to link former and subsequent connections;

5. TLS False State Security Considerations

In a TLS handshake, the Finished messages serve to validate the
entire handshake. These messages are based on a hash of the
handshake so far processed by a Pseudorandom Function (PRF) keyed
with the new master secret (serving as a Message Authentication Code
(MAC)) and are also sent under the new Cipher Spec with its keyed
MAC, where the MAC key again is derived from the master secret. The
protocol design relies on the assumption that any server and/or
client authentication done during the handshake carries over to this.
While an attacker could, for example, have changed the cipher suite
list sent by the client to the server and thus influenced cipher
suite selection (presumably towards a less secure choice) or could
have made other modifications to handshake messages in transmission,
the attacker would not be able to round off the modified handshake
with a valid Finished message: every TLS cipher suite is presumed to
key the PRF appropriately to ensure unforgeability. Verifying the
Finished messages validates the handshake and confirms that the
handshake has not been tampered with; thus, secure encryption is
bootstrapped from secure authentication.



Langley, et al. Informational [Page 5]


RFC 7918 TLS False Start August 2016


Using False Start interferes with this approach of bootstrapping
secure encryption from secure authentication, as application data may
have already been sent before Finished validation confirms that the
handshake has not been tampered with -- so there is generally no way
to be sure that communication with the expected peer is indeed taking
place during the False Start. Instead, the security goal is to
ensure that if anyone at all can decrypt the application data sent in
a False Start, it must be the legitimate peer. While an attacker
could be influencing the handshake (restricting cipher suite
selection, modifying key exchange messages, etc.), the attacker
should not be able to benefit from this. The TLS protocol already
relies on such a security property for authentication; with False
Start, the same is needed for encryption. This motivates the rules
put forth in the following subsections.

It is prudent for applications to be even more restrictive. If
heuristically a small list of cipher suites and a single protocol
version is found to be sufficient for the majority of TLS handshakes
in practice, it could make sense to forego False Start for any
handshake that does not match this expected pattern, even if there is
no concrete reason to assume a cryptographic weakness. Similarly, if
handshakes almost always use ephemeral Elliptic Curve Diffie-Hellman
(ECDH) over one of a few named curves, it could make sense to
disallow False Start with any other supported curve.

TCP fast open is another security threat: TCP FastOpen Security : The Grumpy Troll