JavaScript IN A WEB CONTEXT does not. That's a problem that's hard to solve without breaking lots of existing pages that assume the single-thread run-to-completion semantics and depend on it.
In Gecko, the DOM code is also effectively single-threaded. Changing that could be done, but would likely have significant performance impact...
In the case of Mozilla, for example, all patches require review by a well-established developer before being committed to the tree. Linux has a similar setup.
> I managed to file 3 different reports in 30 minutes
Did you also file Bugzilla bugs on these? Talkback in general is used to isolate common crash bugs; one-off incidents will never get noticed in the mass of talkback data...
On the other hand, if you file a bug on the crash and link to the talkback incident ID, it will be clear what the stack for the crash is so it can get fixed.
> "SecurityFocus reports an unpatched highly critical vulnerability in Firefox 2.0.
SecurityFocus is lazy, basically.
The testcases that shows the vulnerability in question actually showed two problems -- an exploitable crash and a non-exploitable stack-fills-up crash. The exploitable crash was fixed. The other crash is still being worked on, but it is _not_ a security vulnerability.
Of course if all you do is load the testcase in question, you have no way to know which crash you're hitting. That's where someone who was actually trying to report correctly would put in a little more work, but that's too much to ask of SecurityFocus.
> you'll want to stick with Firefox 2.0 Beta 2 on OS X, like I do.
The problem with that is the lack of security updates for said beta... not to mention security bugs fixes since beta that will be disclosed now that final has shipped.
You mean the fact that in standards mode uses border-box sizing while uses content-box sizing?
At the moment, pretty much anything we do here would be per CSS spec, and as it happens the current behavior is IE-compat (having them do the same sort of sizing broke various sites... and yes, we _are_ talking standards mode).
The problem is that it takes finite (and nontrivial) time to propagate the builds to all the mirrors. Otherwise there'd be no problem putting them up at the same time as the release announcement.
The difference is that Gecko 1.9 (the rendering engine for Firefox 3) has been under development for over year now... If things go as they are, Firefox 4 will have basically the same web page rendering as Firefox 3 and different UI stuff.
> So this features list has some intriguing points but the one that > would make me squeal like a giddy school girl
Historically, the Firefox changelists have tended to not list changes to the core code (like leak fixes) as much as "user-facing" changes. Sort of comes with who's compiling the changelists.
There are in fact a bunch of memory usage fixes in Firefox 2 as compared to Firefox 1.5.
1.1 is incredibly badly written, self-contradictory, and inconsistent with other W3C specs (making it impossible to implement both it and those other specs).
1.2 has most of the same problems (to a lesser degree), _and_ built-in security holes (raw socket access APIs, anyone?).
So implementing all of either one is just not happening. All thank the SVG (also known as "we need a Flash competitor for cell phones; screw everything else") working group.
This would sort of work, except for the fact that the renderings of different documents interact (see translucent iframes) and that cross-calls between the document and the UI are very common (see what happens to the status bar as you move around the page and hover links, for example).
Combine this with all the synchronization mechanisms needed in all DOM code because there's no good way to tell whether you're accessing things in the same process, and the fact that DOM objects can be moved between documents (adoptNode), and the performance really will be t terrible...
There's nothing preventing them from maintaining that patch set in a shared CVS repository (cvs.mozilla.org comes to mind, I admit) so other distros can get the benefits too... Yet I have not seen them sending these fixes upstream. Wonder why.
I suspect that if you want them to do something (like set up a stable "unofficial" branding), you'd do better to actually like... suggest that to them. They might not think of it on their own, you know.
> Currently to modify and distribute Firefox you need to take an effort > to remove the image and remove firefox references.
Actually, no. The name and image are controlled by a configure flag, which defaults to NOT using "Firefox" and the fox/world logo.
So in fact to create Firefox with the Firefox branding from the Mozilla.org source code you have to make an effort. Creating a freely modifiable build, on the other hand, takes less work -- no need for that non-default value of the configure switch.
Patches that cause what's being shipped as Firefox to differ from what's in the mozilla.org CVS need approval. Patches that land in mozilla.org CVS (with the peer review that generally entails from the people familiar with the code being changed) don't need any additional review from Mozilla Corp.
Slashdot Mirror
JavaScript supports multiple threads quite nicely.
JavaScript IN A WEB CONTEXT does not. That's a problem that's hard to solve without breaking lots of existing pages that assume the single-thread run-to-completion semantics and depend on it.
In Gecko, the DOM code is also effectively single-threaded. Changing that could be done, but would likely have significant performance impact...
In the case of Mozilla, for example, all patches require review by a well-established developer before being committed to the tree. Linux has a similar setup.
> I managed to file 3 different reports in 30 minutes
Did you also file Bugzilla bugs on these? Talkback in general is used to isolate common crash bugs; one-off incidents will never get noticed in the mass of talkback data...
On the other hand, if you file a bug on the crash and link to the talkback incident ID, it will be clear what the stack for the crash is so it can get fixed.
> "SecurityFocus reports an unpatched highly critical vulnerability in Firefox 2.0.
SecurityFocus is lazy, basically.
The testcases that shows the vulnerability in question actually showed two problems -- an exploitable crash and a non-exploitable stack-fills-up crash. The exploitable crash was fixed. The other crash is still being worked on, but it is _not_ a security vulnerability.
Of course if all you do is load the testcase in question, you have no way to know which crash you're hitting. That's where someone who was actually trying to report correctly would put in a little more work, but that's too much to ask of SecurityFocus.
> you'll want to stick with Firefox 2.0 Beta 2 on OS X, like I do.
The problem with that is the lack of security updates for said beta... not to mention security bugs fixes since beta that will be disclosed now that final has shipped.
> All that being said, it's pretty ridiculous that Firefox 2.0 is still vulnerable to this.
In all fairness, what it's "vulnerable" to is that the stack grows till the OS kills it. It's not exploitable.
Now it's not pleasant either... but neither is:
while (1) {
alert('Gotcha');
}
Which from a user's point of view is equally bad.
You mean the fact that in standards mode uses border-box sizing while uses content-box sizing?
At the moment, pretty much anything we do here would be per CSS spec, and as it happens the current behavior is IE-compat (having them do the same sort of sizing broke various sites... and yes, we _are_ talking standards mode).
The problem is that it takes finite (and nontrivial) time to propagate the builds to all the mirrors. Otherwise there'd be no problem putting them up at the same time as the release announcement.
It'll hit Software Update when it's actually been released.
See http://weblogs.mozillazine.org/preed/2006/10/the_a ntirelease.html for the Mozilla build team's take on articles like this one.
> # Firefox: 100%
;)
You must be looking at just the last line of the table. Look at the table itself -- there's stuff there that Firefox doesn't support.
Sorry, but claiming that Firefox has 100% CSS2.1 support is just bullshit. And I should know, since I work on said CSS support in Firefox...
The difference is that Gecko 1.9 (the rendering engine for Firefox 3) has been under development for over year now... If things go as they are, Firefox 4 will have basically the same web page rendering as Firefox 3 and different UI stuff.
Most new immigrants walk to the US nowadays. And they do it at night.
> What did they have, 350 million?
More like 290 million, at the peak of the Soviet Union.
> Didn't think the Baltics and Kazakhstan had that many people.
Kazakhstan has about 15 million people.
The three baltic republics together have about 7 million.
For reference, Ukraine has about 50 million. That's the second biggest (after Russia) population of the ex-Soviet republics.
As I recall, Kazakhstan was third. Then Belarus with close to 10 million. Then the others.
> So this features list has some intriguing points but the one that
> would make me squeal like a giddy school girl
Historically, the Firefox changelists have tended to not list changes to the core code (like leak fixes) as much as "user-facing" changes. Sort of comes with who's compiling the changelists.
There are in fact a bunch of memory usage fixes in Firefox 2 as compared to Firefox 1.5.
> It would be nice for Firefox to understand basic HTML 4 from 1997 like em/foo/
Sadly, doing this breaks lots of websites. Too many to be possible.
When distributions submit patches, the get merged. Debian did NOT in fact submit patches.
So basically, "screw the HTML spec in this case", eh? ;)
> I would like these FORCED into new tabs
l a/browser/app/profile/firefox.js&rev=1.164&mark=25 1,254#250
There's already a pref for this. See http://bonsai.mozilla.org/cvsblame.cgi?file=mozil
No UI, but you can set this with about:config.
> Full SVG support
Which "SVG"? 1.1? 1.2?
1.1 is incredibly badly written, self-contradictory, and inconsistent with other W3C specs (making it impossible to implement both it and those other specs).
1.2 has most of the same problems (to a lesser degree), _and_ built-in security holes (raw socket access APIs, anyone?).
So implementing all of either one is just not happening. All thank the SVG (also known as "we need a Flash competitor for cell phones; screw everything else") working group.
This would sort of work, except for the fact that the renderings of different documents interact (see translucent iframes) and that cross-calls between the document and the UI are very common (see what happens to the status bar as you move around the page and hover links, for example).
Combine this with all the synchronization mechanisms needed in all DOM code because there's no good way to tell whether you're accessing things in the same process, and the fact that DOM objects can be moved between documents (adoptNode), and the performance really will be t terrible...
There's nothing preventing them from maintaining that patch set in a shared CVS repository (cvs.mozilla.org comes to mind, I admit) so other distros can get the benefits too... Yet I have not seen them sending these fixes upstream. Wonder why.
I suspect that if you want them to do something (like set up a stable "unofficial" branding), you'd do better to actually like... suggest that to them. They might not think of it on their own, you know.
> Currently to modify and distribute Firefox you need to take an effort
> to remove the image and remove firefox references.
Actually, no. The name and image are controlled by a configure flag, which defaults to NOT using "Firefox" and the fox/world logo.
So in fact to create Firefox with the Firefox branding from the Mozilla.org source code you have to make an effort. Creating a freely modifiable build, on the other hand, takes less work -- no need for that non-default value of the configure switch.
Patches that cause what's being shipped as Firefox to differ from what's in the mozilla.org CVS need approval. Patches that land in mozilla.org CVS (with the peer review that generally entails from the people familiar with the code being changed) don't need any additional review from Mozilla Corp.