Firefox development: A lot is going on

When Electrolysis, the much awaited multi-process Firefox project, also known as E10, was put on hold in Nov. 2011, many FF users were disappointed as it was seen as a major step to catch up with Google Chrome. The reason for this decision was that Mozilla wanted to concentrate on other initiatives that promised a more responsive Firefox in a shorter timeframe. In the meantime, a lot is happening in the background:

There is the Supersnappy project which aims to run chrome and content on different threads.

The MemShrink project tries to reduce the memory consumption of Firefox. Its progress is documented here and here.

While javascript performance has improved a lot in the past, a new engine called IonMonkey will make FF even faster.

Sandboxing would have been a part of E10 - now they are planning a whole-process sandbox. They are also planning an Iframe sandbox among many other security improvements (like click-to-play for plugins).

One of the most exciting projects is Servo. Its goal is a new rendering engine which will be written in the new Rust language (do you hear me, Hungry? ) which offers important security advantages over C/C++. However, I guess its implementation will take some time.

This is only a short list of improvements coming to Firefox. A lot is going on beyond new version numbers every 6 weeks ...

 

tnx for the heads up m8!

sandboxing is the feature i'm really looking forward to.

is there any ETA for that feature?

 

Great news!

Although, as they well mention, the damn plugins will always be an attack vector, such as Java's.

Plugins are not affected as they cannot be run in low rights without their cooperation (ie. code changes).

Adobe has released a beta version of Flash Player that runs in a sandbox.

More developers should follow this trend. Unfortunately, they don't.

 

Sounds great.

 

Very detailed information thank you tlu

 

When these things actually happen, and if nothing has improved on Chrome's end, I might actually switch. Until then... eh.

I'm not impressed by Rust either yet. It aims to be a more secure C/C++ but it's not strict enough. We'll see.

Most of what you've listed is already supported by Chrome (html5/iframe sandbox, sandboxed browser except Chrome's is better) so they'll have to offer more than that. I guess I'd use it if I felt it had at least those things + the fact that I like Mozilla.

 

And to think less than a year ago people were prophecying the slow demise of Firefox...

 

Ssssshhhhhhhhhh... Stop reminding us and showing that you remember what was posted.

 

They need to solve ui responsiveness issue first!

 

OOPS-Sorry. It shows what can happen when you hang around Wilders for too long. You get memory flash-backs...

 

This 100 times over. Whilst I'd love to see all this implemented so that Firefox can catch up, if it's one thing that Mozilla has never been short on doing, it's hyping and failing to deliver. They will probably end up using AppContainer faster than anything else because they don't need to develop it. Hopefully they keep us updated with progress instead of randomly finding out one day that something has been delayed/stopped.

 

I think AppContainer is actually really likely to be what they're referring to by the whole-browser sandbox. It's nice that they're doing that but I'll have to wait and see.

 

@tlu, there's this as well. The pdf.js add-on is here. Anyone tried it?

HM won't let us forget exactly how inadequate Fx is

 

At least they don't charge for doing so.

 

I just tried the pdf.js thingy using Fx 12. It's one of those restartless add-ons. It opened two simple (just text) pdf files stored on my PC in a snap. Let's see how it goes with more complex local files. (I'm more concerned with local files since I mostly don't open pdf files online.)

Edit:
Password-protected files throw up an error.
It's a known issue: https://github.com/mozilla/pdf.js/issues/1228

 

True, true. But with price comes an expected level of quality.

Do you know if they will build it in? Can't count the amount of times I've had to open a PDF on another system and had to wait half an hour for Adobe Reader to load.

 

I think that aspect is being discussed. One thought is to keep it separate so that only those who want it will install it.

 

I couldn't get it to work with Portable Apps Fx. I'd probably have to reinstall it with the PDF plug-in unchecked or something.

I think this behaviour is strongly reactive-formative & deep down he suffers from Firefox-envy syndrome.

 

Or not, as the case may be.

Good reason not to use Adobe.

 

Just a thought but it is javascript and maybe it's blocked in some way?

 

I will probably end up disabling it. I don't see me ditching the Google Docs Viewer extension and Sumatra PDF Portable anytime soon. So far, these 2 have worked perfectly for my needs.

Could you do a small test? Unlock the password-protected and/or restricted PDF with PDFUnlock! online service and see if the pdf.js is able to handle the unlocked PDF file.

 

What I've dones is to unlock "forever" using Evince, the PDF reader that comes with Ubuntu. But pdf.js still doesn't manage such unlocked files. Let's see. It's early days. I'm hesistant to use an online service because these files are usually related to financial matters.

 

Okay, I just made my own password-protected pdf file using the export to PDF in LibreOffice Writer. After passing it through the unlocking link, the downloaded file then opens with pdf.js. But that utility needs to be incorporated into pdf.js sooner or later.

 

Good point, I didn't think of that. I don't know why I run NoScript on a portable for anyway. I'll investigate further.

 

Decided I'd install it. Tried it on a few PDFs and works well, definitely a keeper.