mykmelez

> Again, it seems that for LMDB is again "solving" the problem by ignoring it. Which is OK if it fits your use case... But shouldn't Firefox work properly on 32-bit systems? Or did they completely decide that they don't want to target any 32-bit platform anymore?

Yes and no, respectively. Yes, Firefox should work properly on 32-bit systems; and no, we didn't completely decide that we don't want to target 32-bit platforms anymore.

Rather, Firefox plans to use LMDB where it fits one of its many use cases for persistent storage (and not use it where it doesn't).

The StackOverflow thread you referenced describes a blockchain program that expects to use "a few GB of lmdb diskspace." Whereas Firefox's use cases for LMDB are sized in the range of a few KiB to a few MiB. Firefox has no plans to start storing a blockchain.

Claimer: I'm the engineer integrating LMDB into Firefox.

According to @hyc in https://monero.stackexchange.com/questions/2606/are-the-lmdb..., "As of v0.10.0, yes the LMDB files are cross-compatible between 32 and 64bit architectures. They have always been cross-compatible between OSs. They are still byte-order dependent but almost everyone uses little-endian CPUs these days so it's not much of an issue."

It does require X to be installed, although it doesn't actually use X, and the X implementation can just be Xvfb.

Unfortunately, fixing that is hard. I think Chrome has the same limitation. For Firefox, the issue is tracked in https://bugzilla.mozilla.org/show_bug.cgi?id=1372998.

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.

(Note: I'm the product manager for the headless browsing feature of Firefox.)

I chose to prioritize WebDriver support because it's a popular way to drive headed Firefox, and I wanted to make it as easy as possible for existing WebDriver users to use headless.

For use cases that are not well-served by WebDriver, I've considered supporting the Chrome DevTools Protocol, as @brendandahl noted, although I haven't yet made a decision to do so.

I'm interested to hear more about the use cases you've considered for which WebDriver is a suboptimal solution. Like @brendandahl, I'm in the Bay Area and would be happy to meet in SF or MV.

Great article! I'm the product manager for the headless feature, and I'm unsure why `binary.add_command_line_options('-headless')` doesn't work for you, as the flag does work when invoking Firefox directly:

> "c:\Program Files\Nightly\firefox.exe" -headless

(It also works when Firefox is invoked from a Node.js script in a test suite for a Node.js program that drives Firefox.)

Perhaps this is a Selenium issue?

Hmm, I thought it was obvious that this recommendation applies only during benchmarking by PluotSorbet developers, not when the project is being used to run a midlet. But perhaps not, so to clarify: if you're hacking on PluotSorbet, and you're benchmarking startup, then we recommend you set that preference for the reasons stated; otherwise, you should not set that preference.