16 Commits

Author	SHA1	Message	Date
Tim Düsterhus	16fcc9df2e	Bump version	2023-02-22 17:45:50 +01:00
Tim Düsterhus	118de57bb7	Bump version	2022-09-17 16:24:07 +02:00
Tim Düsterhus	9db3daa2bf	Bump version	2022-03-10 18:56:18 +01:00
Tim Düsterhus	9c3f0db196	Bump version	2022-03-04 21:21:52 +01:00
Tim Düsterhus	e661d462a3	Bump version	2021-03-05 17:19:27 +01:00
Tim Düsterhus	d084315276	Bump version	2021-02-04 23:04:35 +01:00
Tim Düsterhus	c241df9470	Bump version	2020-11-20 00:08:57 +01:00
Tim Düsterhus	8fc2ed4e54	Bump version	2020-11-08 12:30:49 +01:00
Tim Düsterhus	23228c9ed6	Bump version	2020-11-02 21:29:59 +01:00
Tim Düsterhus	3a88e73ee1	Run prettier on all files	2020-11-01 17:41:19 +01:00
Tim Düsterhus	f8dafa2583	Bump version	2020-11-01 17:09:27 +01:00
Tim Düsterhus	7538639d7b	Bump version	2020-10-20 18:03:04 +02:00
Tim Düsterhus	5687d6fabb	Bump version	2020-03-25 23:04:48 +01:00
Tim Düsterhus	26f2679841	Bump version	2018-11-27 20:53:30 +01:00
Maximilian Mader	724540a8b2	Fix enter key check while composing characters ... Chrome on macOS sends a KeyEvent with `key` set to `Enter`, the keyCode `229` and `isComposing` set to `true` when pressing enter while a character composition sequence is active, then an event for the composed key and ends with a Enter key event with the correct key code. This has thrown our Enter key detection off and resulted in sending of the wanted message and a public message with the single composed character as content. Ignoring the Enter key while characters are being composed seems to be safe.	2018-08-22 19:18:09 +02:00
Tim Düsterhus	317ee29461	Initial import	2018-08-17 00:30:59 +02:00