Comment Re:new firefox release schedule moved me to Chrome (Score 1) 383
I was making a general point, not especially directed at you.
Sorry your experience with Firefox has worse than the norm, though.
I was making a general point, not especially directed at you.
Sorry your experience with Firefox has worse than the norm, though.
Firefox 10 or 11 will assume add-ons are compatible by default, which is more or less what you're asking for
There will be a few exceptions, such as add-ons with binary components and add-ons that are known to not work.
Remember: A bug not manifesting in your instance of a program is not the same as the program being bug free.
Conversely, a bug manifesting in your instance of a program is not the same as the program being a bug-ridden piece of crap written by insane monkeys.
A browser is many of the many apps i run on my systems
FTFY.
(If you're running an email app, a feed aggregation app, and a social network app in your browser, then your browser is going to use some memory.)
I triaged bugs back in 2000, too. What was your username or email address in Bugzilla?
Nowadays my focuses are security and finding bugs.
In 2009 I wrote about how to make triage more efficient and more effective. (Tyler linked to my post). And I actually triaged a subset of bugs that way when I was tasked with bringing down the number of crash bug reports.
What exactly do Mozilla do with 100 million dollars of tax-free revenue?
The first thing we do with it is to pay taxes. It was not trivial for us to figure out how to do that.
Are they building a war chest?
You can get a sense of how much we're saving by reading financial reports from previous years. To some extent, we're saving not because we want to save, but because we can only hire people so fast while maintaining quality and culture.
That'd be 500 full time employees at 100k per year with 50 million left over in case of emergencies.
500 full time Mozilla employees and contractors isn't far off.
I've heard a rule of thumb that once you throw in benefits, offices, and travel, the cost of employing someone is about twice their salary. I don't know whether that holds for Mozilla, which has generous employee benefits but many remote employees.
every single time, Firebug and Greasemonkey stop working.
If you use a beta version of Firefox and want to use Firebug, the Firebug developers say you should use the beta version of Firebug. It would be nice if Firefox Beta automatically went out and fetched the beta version of Firebug instead of just saying the version you have is incompatible.
Greasemonkey is often more compatible than its authors let on. I'm using it with Firefox 8 Nightly and it's working fine, despite being marked as only compatible with Firefox 5. I bet it would work in your Firefox 6 Beta just fine.
There's also a competitor to Greasemonkey called Scriptish that is marked as compatible with Firefox 6 beta. I've heard good things about it but haven't tried switching yet.
track add-ons better and not refuse to load them just because they haven't yet been certified to work
That's the plan!
AMO-hosted extensions that use APIs that haven't changed are automatically assumed to work. So are extensions developed using the new SDK.
To do it safely for other extensions, we'll need to gather data from beta users (like you -- thanks!) to find out whether the extension still does its job, whether it causes crashes (crash-stats correlations), and whether it causes other widespread problems (telemetry correlations).
Future beta versions of Firefox will probably ask you whether you also want to beta-test extensions that might not be compatible. For now you have to set a hidden pref to do that.
I'm pretty sure "__misaligned_access" in that stack trace is a red herring. Notice the large offsets and multiple frames blamed on the "same function". It's probably a section of ntoskrnl for which you don't have full symbols.
In theory you can get a decent stack trace (or even stack traces for all threads) by following the instructions on How to get a stacktrace with WinDbg. In theory. I tried once and got about as far as you did.
Does that mean the goal of Rust is to become part of Firefox at some point?
Yes, the hope is that parts of Firefox will begin to be written in Rust. I heard a rumor that we might replace our HTML parser first. (Our current HTML parser has one of the weirdest build requirements; it's written in a custom subset of Java that can be source-translated into C++.)
I had always wondered why Mozilla would suddenly become interested in writing a new programming language out of the blue
As opposed to digging deeper and deeper into our unhappy dialect of C++?
Didn't seem like the sort of organization with so much excess resources to throw around that it would be useful to start spinning up such a thing
We're doing pretty okay on money for now
instead of, say, buying more build slaves
IIRC, we were limited there by datacenter power or space. We recently got space in a data center in Phoenix, which should help a lot.
We were also limited there by trying to use the same hardware to test Firefox's performance on all desktop operating systems, which meant using a specific version of the Mac Mini for everything. And using the same hardware for both performance testing and unit testing. We're going to change that.
We're doing as much as we can to reduce those problems while Firefox is still single-process. For example, we recently started throttling timers in background tabs and added a sane web animation API. More and more internal APIs are asynchronous or interruptible. We've also reduced memory use quite a bit with Firefox 7; I think we use significantly less memory than Chrome in common cases now.
At the same time, we're also working on process separation. It looks like it will be ready to play with, perhaps even an option, in a few months. I don't think we'll enable it by default until we're comfortable with the tradeoff between memory use and responsiveness/stability.
And we're also working on a new programming language that could make it safe and sane to use "tasks" (likely mapping to threads) rather than processes, so we don't have to deal with that unhappy tradeoff
I'm curious about the change to rendering. It seems to me they're saying, "these OS layout engines (Quartz et al) are too slow - we'll just route around them".
Precisely the opposite. It's our previous abstraction layer that's too slow, and we're replacing it with a thinner one, starting with the easier things like Canvas. See Introducing the Azure project and Azure vs Cairo.
Does that still happen? I thought we fixed that a while ago, and made it show an error message instead of popping up the profile manager.
Actually, what I want from the Mozilla devs at the moment is not new features, but a solution to Firefox's memory problems.
Then you'll be happy to know that the "latest and greatest" includes some pretty big memory improvements. Do a find-in-page on The Burning Edge for "memory" or read Nick Nethercote's blog.
It seems that it's easier to motivate Mozilla developers to work on memory issues when the fixes will reach users in months rather than years.
I'm using Nightly (7) and I'm having trouble getting Firefox to use more than 400MB (explicit) even after a day of heavy use, with Gmail and Reader and Twitter as app tabs. You should try it out and report any bugs you encounter. Yes, we finally have tools that allow users like you to report useful memory leak bugs.
Or maybe it's a security hole in your extension that it prevents you from keeping Firefox up to date.
And it should be the law: If you use the word `paradigm' without knowing what the dictionary says it means, you go to jail. No exceptions. -- David Jones