4 ms·

Perhaps I'm spoiled, but I'm wondering why this wasn't a thing many years ago. Am I wrong in saying this was brought about in reaction to Chrome adding the same

Perhaps I'm spoiled, but I'm wondering why this wasn't a thing many years ago. Am I wrong in saying this was brought about in reaction to Chrome adding the same feature, or has this been there for a while? Clearly people wanted this for ages, hence the work on things like PhantomJS. But it seems like it was only added once they realized they needed to play catch-up with Chrome.

Manishearth 9y ago
No, this has been in the works for a while https://bugzilla.mozilla.org/show_bug.cgi?id=1338004 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 https://bugzilla.mozilla.org/show_bug.cgi?id=446591)
- tree_of_item 9y ago
  Thanks for the info, that's good news.
  - duck 9y ago
    Or you could look at as really bad news if it takes a decade to implement this.
    - Manishearth 9y ago
      I mean, Selenium has worked for Firefox for years so it's not like this was a priority. 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.
      - hugs 9y ago
        Good enough to be the W3C standard. https://www.w3.org/TR/webdriver/ https://www.w3.org/TR/webdriver/
Macha 9y ago
Possibly contributing factor: the old selenium plugin for Firefox is broken by the webextensions move. While working for that use case, they cleaned up other issues for it? This seems way too fast to be a response to chrome
- Vinnl 9y ago
  This isn't another use case for it; you can still use Selenium with Firefox 57+. It's only the extension that allows you to generate Selenium scripts by performing the tasks you want it to execute manually that will no longer work, and no effort is invested in that because there are good enough alternatives.
feelin_googley 9y ago
http://web.archive.org/web/20070303040640/http://simile.mit.edu:80/wiki/Crowbar http://web.archive.org/web/20070303040640/http://simile.mit.... 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.
mykmelez 9y ago
Hi, I'm the Product Manager for Headless Firefox at Mozilla. 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.

Manishearth 9y ago

No, this has been in the works for a while https://bugzilla.mozilla.org/show_bug.cgi?id=1338004 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 https://bugzilla.mozilla.org/show_bug.cgi?id=446591)

tree_of_item 9y ago
Thanks for the info, that's good news.
- duck 9y ago
  Or you could look at as really bad news if it takes a decade to implement this.
  - Manishearth 9y ago
    I mean, Selenium has worked for Firefox for years so it's not like this was a priority. 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.
    - hugs 9y ago
      Good enough to be the W3C standard. https://www.w3.org/TR/webdriver/ https://www.w3.org/TR/webdriver/

Macha 9y ago

Possibly contributing factor: the old selenium plugin for Firefox is broken by the webextensions move. While working for that use case, they cleaned up other issues for it? This seems way too fast to be a response to chrome

Vinnl 9y ago
This isn't another use case for it; you can still use Selenium with Firefox 57+. It's only the extension that allows you to generate Selenium scripts by performing the tasks you want it to execute manually that will no longer work, and no effort is invested in that because there are good enough alternatives.

feelin_googley 9y ago

http://web.archive.org/web/20070303040640/http://simile.mit.edu:80/wiki/Crowbar http://web.archive.org/web/20070303040640/http://simile.mit.... 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.

mykmelez 9y ago

Hi, I'm the Product Manager for Headless Firefox at Mozilla. 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.