3 ms·

> For most FF is very responsive and there are no problems what so ever. Open dev tools, type `for (;;) {}`. Notice the whole browser becomes unresponsive. Thi

by lloeki 10y ago

> For most FF is very responsive and there are no problems what so ever. Open dev tools, type `for (;;) {}`. Notice the whole browser becomes unresponsive. This has been improved upon (as in it doesn't block the whole Firefox UI, just merely every single content tab) thanks to Electrolysis partially reaching stable but "there are no problems whatsoever" simply isn't true performance wise (and this is the most obvious one, there are numerous other very well known performance issues with FF)

tarancato 10y ago
I have an easy metric for that: when you're navigating, look at the "loading" spinner on the tab bar, and see how it almost always freezes every time a page is being drawn. DOM painting/manipulation times in Gecko are a joke, probably the worst pain point of Firefox. And it's not the only one...
wldcordeiro 10y ago
Run an infinite for loop and look at the performance degradation is about the dumbest test you could do. That's literally asking it to not stop executing. Yeah tab isolation would mean you only crash a tab but that isn't a good example.
- tarancato 10y ago
  So you tell me it's reasonable that a frozen tab makes the whole browser unresponsive. Nice.
syrrim 10y ago
Open your terminal, type ':(){ :|:& };:'. Notice how the whole OS becomes unresponsive. There is a very simple solution to both these problems, which most people employ to great effect: just don't do that.
- lloeki 10y ago
  Besides that doing `perl -e 'for (;;) {}'` and watching your OS burn down in flames (which it doesn't) is the correct parallel, I'll assume you have overlooked that we have no control on what JS does in whatever page we're presented with, and if it's some heavy handed code it has a significant impact on whatever else I may be doing on an unrelated tab, which feels like going back to plain old cooperative multitasking, upon which the above perl code would effectively be a blight.

by lloeki 10y ago

tarancato 10y ago

I have an easy metric for that: when you're navigating, look at the "loading" spinner on the tab bar, and see how it almost always freezes every time a page is being drawn. DOM painting/manipulation times in Gecko are a joke, probably the worst pain point of Firefox. And it's not the only one...

wldcordeiro 10y ago

Run an infinite for loop and look at the performance degradation is about the dumbest test you could do. That's literally asking it to not stop executing. Yeah tab isolation would mean you only crash a tab but that isn't a good example.

tarancato 10y ago
So you tell me it's reasonable that a frozen tab makes the whole browser unresponsive. Nice.

syrrim 10y ago

Open your terminal, type ':(){ :|:& };:'. Notice how the whole OS becomes unresponsive. There is a very simple solution to both these problems, which most people employ to great effect: just don't do that.

lloeki 10y ago
Besides that doing `perl -e 'for (;;) {}'` and watching your OS burn down in flames (which it doesn't) is the correct parallel, I'll assume you have overlooked that we have no control on what JS does in whatever page we're presented with, and if it's some heavy handed code it has a significant impact on whatever else I may be doing on an unrelated tab, which feels like going back to plain old cooperative multitasking, upon which the above perl code would effectively be a blight.