Port the renderer cross-platform, and write separate native apps for each target platform. The amount of complication and cruft that must be in the codebase for making a massively complex software package like Firefox work cross-platform, and the amount of basic OS-level functionality that must have to be reimplemented from scratch because it isn't available on some particular target platform, is probably no small contributor to its performance woes.
"Of course we won't use DirectShow / QT / GStreamer as an alternate backend for <video> -- that would make it actually useful in the real world, and our Theora evangelism comes first!"
The video wars were because [Apple, MS, Real, Macromedia, Sun] were all trying to compete with each other using crap products that conflated [Branding, Plugin, Container Format, Codec] in a mash of uselessness.
Flash won not because it had the same codecs on all platforms, the plugin was customizable the same way on all platforms, and the end-user branding was all yours to theme.
The most interesting part of <video> is not codecs or containers, but the full + uniform control and customizability via its Javascript API. The only reason there is any problem at all is because Mozilla is refusing to expose access to QT / DirectShow / GStreamer.
Mozilla threw all of their weight behind XULRunner years ago. It probably wasn't that bad of a decision, given how much of a headache it is to use Gecko directly.
Even doing the core rendering part cross-platform has a lot of technical issues as the platforms provide a lot of functionality that can be leveraged by the rendering engine (typesetting, drawing, animation etc...). Consequently, the more you want to integrate with the native facilities of the platforms, the more interfaces and glue components you need in order to hook the platform independent part up to the native facilities. This leads to a loads and loads of ceremonial code and interfaces that introduce additional layers of complexity.
Native apps for each platform may give performance boost, but maintaining a consistent UI will be a lot harder
If we want native UI, it's obviously going to have major inconsistencies between platforms!
I think they've actually done a really good job making it look like a native app instead of just a port from some other OS.
Fun Fact: In Safari since version 3, the <input> elements aren't actually native widgets anymore, as NSButton et. al. couldn't support a bunch of the CSS attributes. They are now rigorous behavior-level reimplementations!
A widget that looks native but behaves differently is terrible! At least when it looks alien you don't expect it to behave natively.
However they do obtain additional (optional) entropy (if you're familiar with the NIST DRBG's, then I'm talking about the 'Additional Input' parameter) by reading system time while periodically reading a bunch of system dirs to advance time in a non-deterministic manner. And that's where this bug creeps up.
It is calling a kernel interface. The prefix "Rtl" means that it is in the kernel run time library.
Reference: http://blogs.msdn.com/wdkdocs/archive/2008/12/19/windows-ker...
How often do you see a forensic analysis of this type on commercial software? Not zero, but less often.
(I have to admit it's sort of more impressive when someone whips out a debugger rather than reading through source.)
Were it a problem within IE (or Oracle applications - let's be fair as this is not a Microsoft-only problem) we would have to wait until a developer reads the report, the bug being assigned and the correction being put in a future bug-fix release.
In a way, a guy from Microsoft just made a huge point on how open-source is far superior to their own closed development cycle.