A Try at a New Firefox

We have had Bezilla for a long time and being that it’s based off of Firefox 1.8, it may be time to port A newer version of Firefox. I have looked through the code and see there is a widget backend for qt so a minimal build without extras could be possible. I know there still would be a lot more effort than that to porting Firefox again, though it would be nice to have a major browser available on Hiaku. Hope somebody could consider this.

I like Webpositive, but it doesn’t hurt to have more than one choice :slight_smile:

It does look like we have most of the dependencies for a Qt build. But the last version of firefox that supported Qt is two years old (https://github.com/tmeshkova/gecko-dev/tree/qtbackendrefactor). If Qt was supported as a mainline firefox build then it would be great, but is there really any point in porting a random version from 2 years ago?

EDIT: Hmm, this looks more recent: https://cgit.gentoo.org/proj/mozilla.git/commit/?id=1417b0d0d58d2f11b54fe8edf1495dec5de4ccc4

Mozilla’s latest thing is the Servo browser (that is supposed to be available as an alpha release in May). It’s built on their new Rust programming platform, which may or may not be easily ported to Haiku. Since Rust is much more memory safe than C/C++, it is thought that Mozilla may slowly move FF over to it, or merge with Servo, although that is all conjecture currently.

I built the very first development version of Servo, and thought it had potential. Time will tell …

Guess what, there’s already a recipe for Rust: https://github.com/haikuports/haikuports/blob/master/dev-lang/rust/rust-1.2.0.recipe

Probably needs an update to a more recent version already as they keep changing the language.

@pulkomandy: Positively excellent! Will check it out… Thanks.

It remains to be seen if Cargo has been ported as well :slight_smile:

Edit: hour later …
Just for grins, I tried to build Servo on Haiku:

First, I copied these packages into /system/packages:

rust_x86_runtime-1.6.0-1-x86_gcc2.hpkg rust_x86_source-1.6.0-1-source.hpkg rust_x86-1.6.0-1-x86_gcc2.hpkg

I symlinked the system dirs as a quick-and-dirty …

git clone ht tps://github. com/servo/servo.git
cd servo

./mach  build
        ---- >Python virtualenv is not installed. Please install it prior to running mach

 pip install --upgrade virtualenv
        ---- >  pip: command not found

I Guess there’s no pip on Haiku’s Python yet?

Anyway, Servo looks interesting for Haiku because of the graphics abstractions. On Linux, Servo uses rust-layers, which is a graphics abstraction layer that uses GLX (OpenGL X extension) in the Xorg display server.

Recently, the servo project used a subproject at NCSU to refactor servo and rust-layers to add support for EGL, so ultimately for Wayland too.

Would this reduce the complexity of a port to the Haiku native platform windowing system and underlying subsystems?

I understand that I’m:
a) digging up old threads
b) posting about something not really firefox-related

But someone mentioned pip and python up there and I guess this might be useful!

Well, while pip almost works on Haiku (you need to manually install it and it won’t close itself after successful install), magic happens when entering pip+virtualenv territory.

And by magic, I mean stuff spectacularly falling apart.

Okay, so in theory, while making a virtualenv with “virtualenv” command, it should just install pip, setuptools and wheel in that new env, right? It doesn’t. It completely ignores that fact and installs those into the main python env. Does it make sense? NOT. AT. ALL.

But don’t worry, you can totally just run pip and install packages…
… into the main env. I guess it makes sense since it’s just running a “pip” binary that’s in the PATH.

Okay, so what about copying those manually? It makes the whole point of using a venv disappear but still. Sure. You can manually copy packages to env/lib/python2.7/site-packages and it works. I ran a simple website coded in Django just to confirm that.

What about python -m pip? - you might ask.
I tried using it to install setuptools and it didn’t work as expected. It’s hard to confirm whether it’s working or not without setuptools, I guess.

So it seems to me, that we need a pip port that actually works.