https://bugzilla.mozilla.org/show_bug.cgi?id=1338004
So not in reaction to Chrome.
In fact, the first attempt for this was almost a decade ago (https://bugzilla.mozilla.org/show_bug.cgi?id=446591)
It's a decade to decide this is worth doing, which is reasonable given that there's also a "good enough" solution out there; Selenium.
No, this wasn't a reaction to Chrome. We decided to implement headless mode last fall after research last summer indicated that it would increase website testing in Firefox and thus improve web compatibility.
Of course, I was aware at the time of Chrome's own efforts to implement a headless mode, and I've continued to pay close attention to their work.
I've also made similar decisions to Chrome at times (f.e. to use the same --headless command-line argument to enable the mode), while making different decisions at other times (like deciding to prioritize support for the WebDriver API, whereas Chrome has focused on support for the Chrome DevTools Protocol).
But my focus has been primarily the direct benefits to web developers of being able to run tests against headless Firefox; and the indirect benefits to Firefox web compatibility of more web developers testing on Firefox.
I remember using this with xvfb to achieve headless Firefox. The rendered text could then be accessed via localhost with a text-only browser or tcp client e.g. netcat.
This seems way too fast to be a response to chrome