Earlier quoted context omitted.
They are using asynchronous queries still, and the problem is that they aren't always asynchronous if there are any long-running queries happening in the background. That's the reason for the hang per the most recent bug. If temp tables were causing problem, then there's something seriously wrong with SQLlite's in-memory temporary tables (or how they are being used). By definition they shouldn't be blocking...
Firefox was creating memory-backed temporary tables and syncing them to disk; however, the process of regularly syncing to disk while using the browser caused issues. It also added to start-up time requirements. For example, if you don't want to hold the entire history in memory but only the most recent changes, you have to create a view spanning the temporary table and the on-disk table to do history queries (so the…
Dear Mozilla: Fix Your Damn Browser
151–160 of 211 posts
Re: Dear Mozilla: Fix Your Damn Browser
#152Oh well, I've been using Firefox since it's pheonix, firebird days! I've never evangalised so hard about a piece of software, and every Linux and Apple user owe it a debt of gratitude, in as much that it was a good cross platform browser. Performance wise, some upgrades have been for the better some for the worst. But don't get too sentimental about past incarnations. I remember there being memory issues in the 2.x l…
> Those that have dozens of tabs open - I do think you need to ask yourself why? Spatial memory. If my tabs are not exactly where I left them last week, I utterly forget what I was doing. (I'm one of those people whose room looks like a mess but I can tell you where anything is -- so long as no-one's moved it.) If tabs are slowing things down, then the browser should "background" tabs that haven't been used in a whil…
This would massively break the web. Even throttling setTimeout() calls for tabs in the background caused breakage.
Re: Dear Mozilla: Fix Your Damn Browser
#153Earlier quoted context omitted.
> Sure, the impact of any specific bug is limited--but the gestalt of Firefox is of a development process that values press and feature creep over performance and correctness. I'm not sure if you are just trolling or not. Assuming not, then since Firefox's development is done in the open, I assume you have some evidence for this - meeting notes or such that show that? Or some other evidence? The evidence to the contr…
Not trolling, but perhaps I was unclear. First, my information is about a year out of date. I only used FF (well, Mozilla Suite/Galeon/Phoenix/FF) from around 2001-2010, and it's clear the FF team has moved to improve performance since then. Perhaps my impressions from that time frame are no longer valid, but the issues I checked in Bugzilla while writing my post seemed largely unresolved. I said "gestalt" to critici…
WebKit doesn't have load events for stylesheets either, for example. It has buggy CSS selector matching, on purpose (doing the right thing was deemed too slow). There are multi-year-open bugs in V8 and Chrome, and that whole project hasn't even had an open bug database for more than a few years.
So I'm not sure the development culture is any different. You just haven't had a chance yet to file a bug and get it ignored by the WebKit folks for a few years. It happens all the time....
Re: Dear Mozilla: Fix Your Damn Browser
#154Earlier quoted context omitted.
And yet, at each release, it seems the focuses on UI changes are the more important... I've seen almost no UI changes in Firefox 5, 6, 7, 8 and 9. All the change-logs were basically backend optimizations.
"I've seen almost no UI changes in Firefox 5, 6, 7, 8 and 9." So.. in the past 2 weeks? Seriously, that absurd numbering scheme needs to stop too.
Re: Dear Mozilla: Fix Your Damn Browser
#155Earlier quoted context omitted.
The responses from Mozilla, Asa especially, have either been, "We don't think that's a problem", or sometimes, "go piss up a rope". I don't think this is very fair to the Mozilla folks. From the few people that I've met (and complained to about Android Firefox) the response has been "why don't you grab the latest version and see if that fixes the problems?" And if it doesn't, then the response is "file a bug." While…
I was referring partly to Mozilla's responses to the reaction from corporate support people over their forced-updates announcements. But, they've also had display bugs around for almost 10 years [1], and they've banned bug submitters over etiquette issues without actually addressing the bug in question [2]. And now for the part that will probably make me really unpopular here: if they fix major issues in an upcoming…
Re: Dear Mozilla: Fix Your Damn Browser
#156I remember one of my co-workers telling me that Firefox was running great for him now that he'd upgraded from 4GB of RAM to 8GB. It finally wasn't slowly grinding to a halt any time he had more than a handful of tabs open for more than an hour or two. Seemed a bit like Stockholm Syndrome to me.
I have a different problem. Firefox now aggressively trims memory usage - over-aggressively trims it, to the point that switching tabs incurs a 0.5 second pause as it reallocates memory it had thrown away. This is Firefox 7, and is most noticeable in image-heavy websites.
There is work ongoing to limit the redecoding to only the things that are visible in the viewport to alleviate this problem.
Re: Dear Mozilla: Fix Your Damn Browser
#157Earlier quoted context omitted.
The responses from Mozilla, Asa especially, have either been, "We don't think that's a problem", or sometimes, "go piss up a rope". I don't think this is very fair to the Mozilla folks. From the few people that I've met (and complained to about Android Firefox) the response has been "why don't you grab the latest version and see if that fixes the problems?" And if it doesn't, then the response is "file a bug." While…
I was referring partly to Mozilla's responses to the reaction from corporate support people over their forced-updates announcements. But, they've also had display bugs around for almost 10 years [1], and they've banned bug submitters over etiquette issues without actually addressing the bug in question [2]. And now for the part that will probably make me really unpopular here: if they fix major issues in an upcoming…
But that bug has been addressed, and however valid your bug might be, you will be banned if you persist in being toxic.
Re: Dear Mozilla: Fix Your Damn Browser
#158Since we’re on the topic of longstanding Firefox issues: Add support for `display: run-in` already. You are the ONLY browser not to support it. http://www.quirksmode.org/css/display.html Last I brought this up, I was told: 1. that it wasn’t completely defined, and some edge cases can arise 2. that it 'wasn't necessary' as you could 'solve' the problem by adding more (wrapping) markup 3. that `run-in` was going to be…
What other browsers do is completely insane (e.g. removing a block that a run-in has run into makes the run-in just disappear altogether in WebKit), so implementing it would be actively bad for the web.
> It’s only being dropped from the spec because they can > finalize the spec if it is 100% implemented by 100% of > the major browsers.
They can finalize the spec as long as every feature is implemented interoperably by _two_ browsers.
There are three run-in implementations, and they're completely incompatible. The feature got dropped from the spec because the working group couldn't figure out any way to even define a restricted behavior subset that Presto, Trident, and WebKit implement the same way.
So no, Gecko's lack of implemetation here didn't block the spec in any way. The fact that all three existing implementations are completely incompatible with each other and all horribly broken had a lot more to do with it.
Re: Dear Mozilla: Fix Your Damn Browser
#159Earlier quoted context omitted.
> Sure, the impact of any specific bug is limited--but the gestalt of Firefox is of a development process that values press and feature creep over performance and correctness. I'm not sure if you are just trolling or not. Assuming not, then since Firefox's development is done in the open, I assume you have some evidence for this - meeting notes or such that show that? Or some other evidence? The evidence to the contr…
Not trolling, but perhaps I was unclear. First, my information is about a year out of date. I only used FF (well, Mozilla Suite/Galeon/Phoenix/FF) from around 2001-2010, and it's clear the FF team has moved to improve performance since then. Perhaps my impressions from that time frame are no longer valid, but the issues I checked in Bugzilla while writing my post seemed largely unresolved. I said "gestalt" to critici…
You also seem to be assuming that the same people who build new features can also fix your pet peeves. While there is an opportunity cost, agreed, it doesn't mean that
- the same people can do both
- it's actually worth doing both in the first place. The opportunity cost of trying to make software perfect is too enormous for anyone but NASA and the like.
edit: Well, looks like I've been hellbanned. Goodbye, Hacker News. It wasn't entirely nice knowing you.
Re: Dear Mozilla: Fix Your Damn Browser
#160Earlier quoted context omitted.
I've got an Asus EEEpc with 2GB of RAM and 4GB swap and I always have Firefox open with 80+ tabs in 4+ windows. After a week or so it'll get really slow when loading and would crash in a day or two if usage continued, so I just kill it and it reloads everything. This "more than a few tabs" or "more than an hour or two" is craziness? What is your friend running?
See, the problem here is that I do that with Opera on my EEEpc too, except I only have a gig of ram, no swap, and I don't have to kill it every week. Firefox just doesn't cut it.
What OS are you in? How long do you keep it running like this? Sounds good.