Hacker News Reader

Comment by aeurielesn | Hacker News Reader

I hope the mobile OS doesn't blackout as the Firefox navigator tends to. I lost all hope on Firefox because of this behavior.

I don't know if this has been fixed. But anyways, I won't go back to Firefox.

View on HN

Mozilla appears to be working on this[0], and improvements are already being seen. (Just as they are vastly improving all the other aspects detractors like to bring up, e.g. memory usage[1], including that of addons via the "Hueyfix"[2].)

[0]: https://wiki.mozilla.org/Performance/Snappy [1]: https://wiki.mozilla.org/Performance/MemShrink [2]: http://blog.kylehuey.com/post/21892343371/fixing-the-memory-...

This is somewhat of a worry - I love Firefox and use it all the time, but it does freeze up occasionally for a few seconds. Which is acceptable in a browser, but completely useless when making phone calls.

That is not normal behavior. Have you tried disabling addons to see if that may be the problem? Otherwise I'd suggest trying a new profile (if you've been using Firefox for a long time. Firefox Sync can help you keep your settings as you migrate to a new profile.)

It could be addons. Hard to tell, I'm running several.

I haven't recreated my profile in a while, possibly time to give that a go.

Before you recreate your entire profile, try the new ‘reset Firefox’ button: https://support.mozilla.org/en-US/kb/reset-firefox-easily-fi...

I just diagnosed and fixed a pausing issue with one of my Firefox extensions. The hard part is getting a reproducible case. But once you do, it's usually just a matter of doing a binary search through extensions, enabling and disabling half the candidates until the culprit is found.

A quick verification can be to start Firefox with the -profilemanager flag and create a new profile, and verify if it does or does not occur in a completely fresh profile.

In my case, pauses came from FoxyProxy regular expression pattern matching on urls where I was using:

  (.*\.)*

to match subdomains. The issue went away when I did:

  (?:.*\.)?

instead - non-capture, and of course noticing that . matched \. too.

I see that happening to Chrome as well. Freezes for seconds doing intensive hard drive work.

So, one thing that myself and others on the team have been working on is moving things out of the main thread/process. There's a big push by the whole team to get everything working cross-process, so that we can start separate processes for each application; that should let us mitigate the problem of GC pauses and the like. One other big push is making everything off-main-thread composited. That lets the graphics work happen more or less independent of the main thread, and frees it up to do standard processing, in addition to letting animations and the like run async (much smoother).

There's a lot of work still to be done, but those pauses should go away over time.

That's fantastic news. I've been very impressed with the amount of improvements Firefox has been undergoing recently.

I should point out that this work is mostly specific to Boot2Gecko. A lot of it is shared with Mobile Firefox, though, and a good bit of it will probably make its way to the desktop eventually as well, but I honestly have no idea on that count (I don't work on Firefox proper).

I hadn't realised that the codebase was so different. How much code is actually shared between B2G, Mobile and Desktop?

Quite a lot. I mean, it's the same Gecko core, but there are a lot of pieces to Gecko. Mobile and B2G both use the same EGL backend for gfx, but they use different widgets and some different optimizations (e.g. we know that we have permissions for gralloc on B2G, so we don't use a tiled backend). Desktop and Mobile/B2G share the layout, JS, etc but you've got all sorts of different gfx backends that could be used. Same code, just a lot of divergent pathways.

Woah dude, that's gotta be damn exciting. Good job.

(It's me from freenode :b )

I'm fairly sure the boot to Gecko project aims to be agnostic as to what rendering engine is used. IE, you should be able to use a Webkit core instead of a Firefox core.

Uh, where did you get that idea from? The rendering engine is even in the name ...

I would suggest using HP/Palm Luna if you want a webkit-based mobile OS. It's apparently using Qt and should be possible to run it on top of android the same as B2G. If Mozilla's work to standardize the APIs goes well the same apps should be usable on both platforms.

... if HP still exists by then :)

Can't find the specific reference now, but seen it mentioned a few times, here's one: http://paulrouget.com/e/b2gdemo/

Their idea is that it is an HTML5 standard with some additional Javascript hooks for hardware access, so any browser could be the 'core' with only a few tweaks.

From your link...

"Gecko on top of it. The same version you'll find on a regular Firefox;"

Maybe we're confusing web standards with rendering engines, but this is a product with only one rendering engine.

Afaict:

- Gaia, the top layer, is meant to be engine-agnostic;

- Boot-to-Gecko / Firefox OS, the complete project, is not.

Yes, that's correct.

Boot to Gecko / Firefox OS is a Gecko based mobile OS. However, the open apps platform we're building lets you run an HTML5 app on, well, any HTML5 device including Chrome, IE9, etc.

This mostly applies to the Marketplace in how it offers paid apps; we have a decentralized receipt format to let the paid app run on any platform. Unlike any other mobile player, Mozilla is truly making the web the platform. Our platform is not Firefox OS. That's just one device to support open web apps.

Reply on news.ycombinator.com