Domain: mozillazine.org
Stories and comments across the archive that link to mozillazine.org.
Comments · 1,913
-
Full Hardware Acceleration
"We're excited that other browsers are starting to optimize for the Windows platform
.. Today, IE9 is the first and only browser to deliver full hardware acceleration of all HTML5 content"
"Microsoft marketing is making noises about IE9 having a monopoly on "full hardware acceleration". They're wrong; Firefox 4 has all the three levels of acceleration they describe. It's surprising they got this wrong, since Paul Rouget published a great overview on hacks.mozilla.org a few days ago (and our plans, source code, and nightly builds have been public since we started working on this stuff many months ago) link
"Firefox's hardware acceleration interacts with a machine's graphics hardware via DirectX or OpenGL, depending on platform" link -
Re:I hope this can be disabled...
The most ridiculous option to be absent from about:config is the option to ignore the no-password-saving flag set on login forms by "super secure" sites, used for everything from online banks to Exchange webmail logins.
IIRC the justification was (and is, as the bug is WONTFIX) that banks would blacklist firefox and that - and I closely paraphrase - "The success of the project takes precedence over the experience of the users." Meanwhile, seamonkey supports the option with no problem, and so does every sane browser.
-
call the waaambulance, turn off indexing.
Thunderbird 3 builds indexes of your mail boxes for every account. If you have huge mailboxes, the indexer is going to need some time to look through it all. You can turn off the indexing if you want through the advanced config editor (global search and indexing)[0].
"By default, Gloda indexing is enabled [93], also for migrating accounts. Note that indexing a large amount of e-mails takes considerable time and resources, especially when setting up a new account or migrating from an old profile! " [1]
[0] - http://kb.mozillazine.org/Mail_and_news_settings
[1] - http://kb.mozillazine.org/Thunderbird_3.0_-_New_Features_and_Changes -
call the waaambulance, turn off indexing.
Thunderbird 3 builds indexes of your mail boxes for every account. If you have huge mailboxes, the indexer is going to need some time to look through it all. You can turn off the indexing if you want through the advanced config editor (global search and indexing)[0].
"By default, Gloda indexing is enabled [93], also for migrating accounts. Note that indexing a large amount of e-mails takes considerable time and resources, especially when setting up a new account or migrating from an old profile! " [1]
[0] - http://kb.mozillazine.org/Mail_and_news_settings
[1] - http://kb.mozillazine.org/Thunderbird_3.0_-_New_Features_and_Changes -
Re:Not entirely random
They didn't have any of those things in 2005 - the time period I was referring to in my post.
Just as you said here - (1) they gave source code dumps, (2) they didn't accept any patches, (3) their source code was filled with platform-specific code, (4) they didn't offer any bug repository even to core KHTML devs, (5) they asked KHTML devs to sign NDAs to see source code they added, etc.
Apple forked WebKit in 2002, and at that point it was as you describe. June 7, 2005 is the date when they created a webkit.opendarwin.org website for WebKit; opened the entire CVS repository with the full history of the project to public checkout; invited publicly-submitted patches (and they committed some of those on the very same day); opened a public bug tracker; and created public mailing lists and IRC channels. See Dave Hyatt's blog post. The first person to get commit access to WebKit who wasn't an Apple employee was Anders Carlsson, in August 2005.
So basically, no. WebKit became a full-fledged open-source project in 2005.
-
Re:Not at all
I use an OS that doesn't suck, I can in fact, have an app trying to use 100% of the CPU and STILL manage to get work done because it won't let it! Its called a 'pre-emptive multitasking OS'. Maybe you should try one.
Yes, I'm aware of multi-tasking, and techniques to avoid process starvation. Some OSes do this better than others. Out here in the real world, employees don't always get to chose which OSes we get to work with.
One core is more than enough for almost everyone. Office apps don't really use a lot of CPU, even Office 2010. What web pages do you use that you run so much JS that you notice it running?
Well, I rarely notice it since I use noscript to avoid all the javacrap. But without noscript, it happens a lot.
Contrary to what Mozilla and Google are ranting about, JS speed hasn't been an issue for years,
Riiiight. So why does firefox have a check for javascript that it running for an extended period of time?
Contrary to popular belief, most people aren't trying to run quake in javascript. Your argument is dumb as it stands.
It's so dumb, that the devs who wrote firefox try to detect it.
-
Re:'Only Area'??? LOL!
> for example, standards don't seem to have been Job One for some time
Standards have in fact been Job One, but the nice thing with standards is that there are so many to choose from. If you don't have the resources to implement them all, or think some of them are actively bad for the web (P3P comes to mind), you don't implement them. See also http://dbaron.org/log/2006-08#e20060818a
For the specific thing keeping Mozilla from a 100/100 score on Acid3, see http://weblogs.mozillazine.org/roc/archives/2010/06/not_implementin.html
What has _not_ been Job One, unlike Apple, is making up new functionality and proposing it for standardization. Maybe it should have been; it's certainly an effective marketing technique for making it seem like you're ahead on standards.
-
Re:Acid test still not 100/100?
The remaining tests target SVG font functionalities which are not being actively developed.
You can find a semi-official rationale for not implementing them here: http://weblogs.mozillazine.org/roc/archives/2010/06/not_implementin.html -
Re:Try it safely on your PC with Firefox Portable
Forecast Fox could be made to work here http://forums.mozillazine.org/viewtopic.php?f=23&t=1876795&sid=20e6ed03a165322bb459cf6a8a180d0d and BetterPrivacy's author has a developer build (1.47.5dev) that works under 4.0beta at http://netticat.ath.cx/Install The BetterPrivacy install crashed my machine (and I run as a limited user). After the restart, the add-on manager showed it installed correctly. I clicked on install multiple times due to me blocking the website from installing add-ons, and the add-on manager didn't allow me to remove extensions (duplicated) before the restart.
-
Re:Chrome, you're losing me!
Firefox 1.5 used less memory than the versions of IE and Opera that were out at the time. The same was true of Firefox 2. Firefox was using less memory than others browsers before Chrome ever existed. There were some memory leaks in Firefox 1.5, but most were fixed by the time Firefox 2 came out, and they didn't cause Firefox to use more memory than other browsers. See http://forums.mozillazine.org/viewtopic.php?t=468525 for details.
-
Re:No more Fireflock. What next?
Or how about the devs saying "the general increase is normal"
http://kb.mozillazine.org/Reducing_memory_usage_(Firefox). or
http://support.mozilla.com/en-US/forum/1/626951Firefox still slowly increases its memory footprint over time. Any other programmer would call that a leak.
-
Re:firefox doesn't really make it easy for the use
Check out this patch if you need to get rid of SSL/TLS errors: link Beware, it was meant to be used on secure isolated networks, it completely disables checking SSL/TLS certificates and will lie to the user telling them all connections are secure.
-
McAfee browser toolbar intrusive and wasteful
McAfee are going in for the hardsell. At work our enterprise uses McAfee Anti-virus products. They've had add-ons to IE and Firefox for some time, but the latest automatic updates were ridiculous. They've added a McAfee toolbar WHICH TAKES UP AN ENTIRE LINE of screen space just to list a little red/green McAfee button. Firefox already lists McAfee as a "problematic extension" but doesn't mention the wasted space problem: http://kb.mozillazine.org/Problematic_extensions
It doesn't affect Chrome. Ironically one of Chrome's selling points it makes maximum use of available screen space. McAfee now makes that even more true! -
Re:using vendor API's !welcome?
To advantage which of it own Apps does Apple use its OS advantage ?
On the iPad, only Apple software can multitask (this article has a list: email client, SMS text client, and other apps). On any of their platforms, only Apple software may use the APIs that let you customize the way the UI widgets display. Only Apple software can use the full functionality of the accelerometer. Here is a blog post discussing some undocumented OS X features that made Safari much faster than Firefox 3. And here is a blog post discussing how several apps were rejected for using undocumented functionality. And here is a whole article discussing undocumented Apple APIs, with examples of cool stuff that only Apple's own software is allowed to do. And here is an article discussing cool things that Safari can do, that Firefox isn't allowed to do. And here is a column that claims that Apple inserts undocumented APIs and uses them in its own code for years, without ever documenting them (but presumably without breaking them because it would break Apple's own code). Even the APIs for the WiFi are undocumented.
I understand the argument that Apple doesn't want to commit to supporting these APIs forever, like Microsoft has had to do with even obscure APIs in Windows. If you use these undocumented APIs to do cool things, and Apple revises the OS, your app may break. And Apple doesn't want the customer to think it's Apple's fault that your app broke.
But I also understand the argument that some of these APIs allow for really cool stuff, which is currently reserved only for Apple. People don't like this.
As for me, give me Linux anyway. No such thing as an "undocumented" API, and there is no entity that has an unfair advantage over everyone else, and I can install any software I want.
steveha
-
Re:I'm all for this
The market share for Firefox is far from stable.
Here. If you dig a little on that blog you'll find the actual sources, which are a mix of reliable web statistics providers.
-
Re:For the patent FUDsters sure to follow....
EU, UK
Neither of these allow software patents (despite what the European Patent Office might tell you).
Do you have a source for that? Better yet, since who knows what "software patent" technically means to a patent lawyer, do you have a source for the claim that H.264 is not patent-encumbered in the UK (for instance)? Because the MPEG-LA's official patent list does include UK patents. Has your lawyer told you those won't actually stand up in court, or are you just parroting wishful thinking that you read on some non-lawyer's blog?
-
Re:H264 patients in various countries
That's not exactly accurate - MPEG LA has been granted patients in numerous countries: http://weblogs.mozillazine.org/bz/archives/020400.html
Yes, it is "exactly accurate". It's just misleading...
In countries without software patents, you can implement an H.264 decoder that runs on your PC, free of charge, no problem. HOWEVER, as soon as that code gets flashed into the firmware of a device, it's now a hardware patent, and you're either paying the patent license fees, or having your devices seized by authorities, in just about any country in the world...
See:
http://news.bbc.co.uk/2/hi/technology/5312696.stm
http://www.reghardware.co.uk/2006/12/15/german_court_rules_on_sansa_snatch/ -
Re:End of Firefox?
"Most of the world" by which metric? If you weight countries by number of Firefox users, most of the world has a patent-encumbered H.264.
Unless you're laboring under the same misapprehension as the Wildfox author about the patent status of H.264. It's patent-encumbered in way more than two countries. See http://weblogs.mozillazine.org/bz/archives/020400.html
-
H264 patients in various countries
"Only two countries in the world have software patents"
That's not exactly accurate - MPEG LA has been granted patients in numerous countries: http://weblogs.mozillazine.org/bz/archives/020400.html
-
Re:H.264 support?
You know, we at Mozilla have all these people working on this problem and amazingly enough, no-one thought of your idea of using the OS libraries yet! How dumb we suddenly all feel... Clearly, you have more brains than all of us put together.
http://weblogs.mozillazine.org/roc/archives/2009/06/directshow_and.html
Gerv
-
Re:Silent update
http://kb.mozillazine.org/Startup.homepage_override_url
I set it to a blank value, and don't get the splash page. -
Re:Good thing
Secondly, and most important, software patents are only really valid in one country with particularly skewed laws, the USA. Even there you'd need to spend minimum US$1 million on a patent lawsuit to see if the patent is even valid, let alone whether it applies to someone using it privately on a home computer.
I don't know about Ubuntu but for Opensuse the patented media codecs are hosted by the Packman project, a perfectly legitimate packaging project based in Germany that provides around 5000 extra packages that aren't in the main Opensuse repo.
The MPEG-LA claims patents in Europe just as in America. Here are some of the ones they have in Germany, following that link: 69129595, 69130329, 3767919, 50306371.1, 50305419, 50311129.5, 69127504, 69109346.6 . . . well, that's going up to page 8 out of 56, and I got bored.
Hey, maybe these are all so frivolous that the MPEG-LA wouldn't even bother suing. But I wouldn't bet on that unless a German patent lawyer has told you so. If the patent office granted them, you'd think a judge would uphold at least some of them, and you only need one to be in big trouble. Packman probably gets away with it because it doesn't have enough money to be worth suing, not because it's actually abiding by the law.
-
Re:Good thing
Unless the term piracy now also includes patent infringement those codecs aren't pirated. They are simply illegal to distribute in the United States because the US allows software patents, and the software is covered by such US patents. The codecs in questions are perfectly legal in any country where software is not patentable.
The MPEG-LA claims H.264 patents in many European countries, including at least: Germany, France, UK, Finland, Italy, Sweden, Belgium, Bulgaria, Liechtenstein, Austria, Czech Republic, Denmark, Spain, Hungary, Ireland, The Netherlands, Poland, Romania, Portugal, Slovenia. Probably more.
Has your lawyer told you that none of these patents will stand up in court in your country? Or is it your own personal expertise that allows you to know what's patentable better than your country's patent office?
-
Re:javascript vs flash
One is compiled then executed in a VM; the other is already compiled and executed in a VM. In the optimal version of each, Javascript will be slower.
Presumably you have the benchmarks to validate your claims? JavaScript was beating Flash two years ago:
http://fupeg.blogspot.com/2008/09/javascript-faster-than-flash.html
Plenty of people are actively migrating away from Flash. Here's an example:
http://github.com/blog/621-bye-bye-flash-network-graph-is-now-canvas
The problem for Flash is that it's going up against browsers with highly optimised JavaScript engines with soon to be hardware accelerated render engines (see Firefox's progress for example). It's all looking a bit grim for Flash.
-
Been done for a longtime
This has been dome for a long time (spelling paypal with similarily looking cyrillic characters. i.e.: "raura" but in cyrillic. or "eVau" for "eBay").
Most browsers circumvent it by either displaying the escaped characters (a.k.a. Punny Code) or by using a different colour to tag non-lating characters (don't know which browser uses this technique).The current difference now, is that the top-level domain, too could be done in non-latin caracters.
i.e.: up until now, the hacks only spellt "PayPal" with seemilarily-looking cyrillics. starting from today a new TLD could be created which looks like "com" but is instead cyrillcs ( "som" in this instance )
Browsers will simply react by showing the escaped form or flag the letters with a different colour.
-
Re:Yay for Google
In fact, Google's share of the search market is declining while Bing's share is rising.
Yes. And privacy might be one of the reasons.
-
Re:The patent lawyers succeeded
We're talking about H.264 here, right? You may want to read http://weblogs.mozillazine.org/bz/archives/020400.html
-
Re:Who reads the manual?
Outside the US there are no software patents, therefore h.264 can't have any patent over it, therefore MPEG-LA can't threaten anybody for anything.
Wrong. The MPEG-LA claims patents in many countries, including much of Europe. Boris Zbarsky of Mozilla looked at the huge list of H.264 patents, and came up with the following countries where some aspect of H.264 is patented:
- Europe: Germany, France, UK, Finland, Italy, Sweden, Belgium, Bulgaria, Liechtenstein, Austria, Czech Republic, Denmark, Spain, Hungary, Ireland, The Netherlands, Poland, Romania, Portugal, Slovenia
- Asia: Japan, China, South Korea, Hong Kong, Singapore, Taiwan, India
- Americas: Canada, Mexico
- Australia
He said he only looked at the first 6 pages out of 43, and wasn't looking very carefully, so there are probably patents in many more countries too. Needless to say, they only need one patent per country to force you to pay royalties.
-
Re:I need some clarifications about HTML5
I'll answer to myself: regarding point 2, we have the opinon of a Mozilla dev against this idea:
http://weblogs.mozillazine.org/roc/archives/2010/01/video_freedom_a.html -
This is a Mozilla Problem
I have the same issue in Seamonkey, just posted about it on the Mozillazine forums as well. http://forums.mozillazine.org/viewtopic.php?f=5&t=1811375
-
just block "document.write" ...
If we are not allowed to talk about AdBlock plus, then lets talk about "document.write".
Most (probably all) ads are created with "document.write", so simply block "document.write". And enable "document.write" for the few sites that you really enjoy.
Add the following to "prefs.js" (seamonkey, firefox,
...):user_pref("capability.policy.default.HTMLDocument.write", "noAccess");
user_pref("capability.policy.trusted.HTMLDocument.write", "sameOrigin");
user_pref("capability.policy.trusted.sites", "http://localhost http://forums.mozillazine.org/ ... ");
user_pref("capability.policy.policynames", "trusted");See http://www.mozilla.org/projects/security/components/ConfigPolicy.html for more details
... -
Re:OpenGL for other OS?
Mozilla is working on hardware acceleration for Linux and OSX, yes. Recently, they landed support for limited OpenGL acceleration on the Windows side which will be working across all OSes eventually.
http://weblogs.mozillazine.org/roc/archives/2010/04/layers.html -
Re:Hey everyone, this is Microsoft!
What they call "layers" (which is what they wrote for this hardware acceleration) does support OpenGL as well as DirectX.
They've explained (sorry, can't find the link) that the Intel drivers for a lot of cards don't ship OpenGL 2.0 drivers. So they need to use DirectX for Windows. They also explained that they're using Direct2D for the layers backend, which needs DirectX 10.
-
Re:How about OpenQuartz?
As I said before, I truly hope Google and all the other browser players 'get it' or we will see a world where IE9 becomes preferred for advanced HTML5 content and will either make IE king again or kill good HTML5 progress on the web.
Firefox is likely to have a release out with hardware accelerated rendering before IE9's release. See:
http://weblogs.mozillazine.org/roc/archives/2010/04/layers.html
http://www.basschouten.com/blog1.php/2010/01/18/layers-cross-platform-acceleration
http://www.basschouten.com/blog1.php/2010/03/02/presenting-direct2d-hardware-acceleratio -
Re:Correct
Apologies. Now that is actually a good point. Of course, you can install an extension to vacuum places.sqlite (or do it manually) and remove residual data from the file. It's still going to be on disk until overwritten, but then the question is where does your need for privacy stop. As far as the browser is concerned, deleting the rows is enough, as nothing running in the browser will have access to the residual data left in the file (hence no css snooping on the history and so on). I would say that deleting should be followed by a VACUUM call anyway (since it's really a good place for it) but that's the devs' call to make. OTOH, if you're worried about someone grepping strings in the file, then you've bigger problems than just the history - it means someone has either local access or at least remote shell access. That's 'slightly' beyond normal expectations of privacy from a mere browser. Regardless, I agree that a vacuum should take place, if only to speed up normal queries to the history.
As far as the bookmarks history goes, it looks like a convenience feature to avoid data loss if the system crashes. Feel free to set browser.bookmarks.max_backups to 0 in about:config. Obscure, yes, but if you need this level of forgetfulness from the browser then you have to dig a little deeper anyway.
However, these problems are not what a regular user would care about, and it's always a fine line to balance between security and usability. The fact that you can take care of them, even though it's far from the most common user scenario, is a plus in my book.
-
Re:It's been said, but it's important
Today, people have data in H.264 format. A lot of data. A long list of hardware devices are made that support it directly. This data is not going to vanish, and people will want to play it. Firefox can choose to support that, or they can choose to become less relevant over time.
The often made assumption is that H.264 is ubiquitous. But it really isn't. H.264 usage, particularly on the web, is highly concentrated. If YouTube said tomorrow that they were going to move to VP8 for all new videos, 70% of all new web video would be in VP8. The change would happen over night. When you've got such large amounts of content managed by so few players (YouTube, Vimeo, etc) it's very easy to force large change very quickly. Certainly Google's press release after the acquisition of On2 seems to indicate that is exactly their plan:
http://investor.google.com/releases/20100219.html
It's worth reading Mozilla's Robert O'Callahan's response to John Gruber:
http://weblogs.mozillazine.org/roc/archives/2010/03/amor_robustum.html
Really the only pragmatic choice is not to compromise on open web standards. Every time it's happened historically, it's been a problem that wasn't worth having in the first place.
-
Legal consequences (Sue Linus)
When do you think Linus Torvalds will get sued?
He installed the Gstreamer ugly plugins
https://bugzilla.redhat.com/show_bug.cgi?id=439858#c19
and ugly includes MPEG-LA patents
http://gstreamer.freedesktop.org/data/doc/gstreamer/head/gst-plugins-ugly-plugins/html/
and users have patent liability:
http://weblogs.mozillazine.org/roc/archives/2010/01/h264_licensing.html -
Re:Firefox not playing h264 is a political decisio
Oh, how so? Outside US, that is?
H.264 is patented outside the US. Including most of Europe, for instance – that post lists 20 European countries. And Canada, Australia, Japan, India . . .
-
Re:Firefox not playing h264 is a political decisio
You don't get it. If Firefox had h.264 support, it could not be redistributed. Period. Everyone would have to download the 'offical' version from Mozilla. No Linux distro could include it. No one could change the code and distribute it. It would cripple Firefox. Why the hell doesn't anyone understand this?
That's not true. All of Mozilla is licensed under the LGPL or a more permissive license, so it can be linked to patent-encumbered (or, indeed, completely proprietary) code. At most, they might have to license the actual H.264 implementation under some non-GPL-based license, to avoid anti-patent clauses of some kind, but Google's lawyers don't see this as a problem with their use of ffmpeg under the LGPL, so I doubt it.
Linux distributions already ship H.264 codecs, so saying they wouldn't ship Firefox if it supported H.264 is unreasonable. Chromium supports H.264 if you compile it to do so, but I haven't heard of any distro saying they won't ship it for that reason. Indeed, fta's PPA package of Chromium already supports H.264 if you install ffmpeg with non-free codecs.
In short: you're wrong. Mozilla is acting on purely ideological grounds, not practical ones. Correctly so, in my opinion, although they'll probably lose in the end. This is not the first time they've taken a principled stance on what features to support, and nor should it be the last. Browser implementers should be moving the web forward in the long term, not just acting in their users' immediate self-interest.
-
Re:H.264
That a patch has been accepted for Fennec already suggests that there may be more movement here in the future. Don't assume that all patch acceptance is politically driven.
I don't need to assume anything, it was all spelled out explicitly:
"Mozilla should pick up and use H.264 codecs that are already installed on the user's system.
I've previously written about a variety of reasons this would be a bad idea, especially on Windows. Really there are two main issues:
Most users with Windows Vista and earlier do not have an H.264 codec installed. So for the majority of our users, this doesn't solve any problem.
It pushes the software freedom issues from the browser (where we have leverage to possibly change the codec situation) to the platform (where there is no such leverage). You still can't have a completely free software Web client stack.But I could just download gst-plugins-ugly and I'd be OK.
That's a selfish attitude. Everyone should be able to browse the Web with a free software stack without having to jump through arcane hoops to download and install software (whose use is legally questionable)."Also see this.
Mozilla is trying to ensure it doesn't end up on an expensive hook if the licensing for H.264 turns sour. There is nothing technically blocking this sort of development - legal issues are sadly more convoluted, move at glacial pace and subject to all sorts of wrangling.
What legal issues could possibly involve Mozilla, if it doesn't ship an actual implementation of H.264 with the browser?
-
Re:H.264
That a patch has been accepted for Fennec already suggests that there may be more movement here in the future. Don't assume that all patch acceptance is politically driven.
I don't need to assume anything, it was all spelled out explicitly:
"Mozilla should pick up and use H.264 codecs that are already installed on the user's system.
I've previously written about a variety of reasons this would be a bad idea, especially on Windows. Really there are two main issues:
Most users with Windows Vista and earlier do not have an H.264 codec installed. So for the majority of our users, this doesn't solve any problem.
It pushes the software freedom issues from the browser (where we have leverage to possibly change the codec situation) to the platform (where there is no such leverage). You still can't have a completely free software Web client stack.But I could just download gst-plugins-ugly and I'd be OK.
That's a selfish attitude. Everyone should be able to browse the Web with a free software stack without having to jump through arcane hoops to download and install software (whose use is legally questionable)."Also see this.
Mozilla is trying to ensure it doesn't end up on an expensive hook if the licensing for H.264 turns sour. There is nothing technically blocking this sort of development - legal issues are sadly more convoluted, move at glacial pace and subject to all sorts of wrangling.
What legal issues could possibly involve Mozilla, if it doesn't ship an actual implementation of H.264 with the browser?
-
Re:H.264
Maybe it will be possible to have a pluggable video decoder for Firefox for the HTML5 Video tag so you can hook up your own solutions. That might solve the issue for everyone.
It would have solved the issue for everyone. The problem is that Mozilla explicitly refuses to do that for ideological reasons!
The link you supply is for a strictly-Windows-only solution. Supporting DirectShow codecs is fine for Windows (maybe) but it doesn't help for cross platform. GStreamer DOES exist for Windows and MacOS X and would be a better starting point.
That a patch has been accepted for Fennec already suggests that there may be more movement here in the future. Don't assume that all patch acceptance is politically driven. Mozilla is trying to ensure it doesn't end up on an expensive hook if the licensing for H.264 turns sour. There is nothing technically blocking this sort of development - legal issues are sadly more convoluted, move at glacial pace and subject to all sorts of wrangling.
Cheers,
Toby Haynes -
Re:H.264
However, right now any implementation of H.264 in the core of firefox is not going to happen.
No-one is asking for that. In fact, you yourself go on to say...
Maybe it will be possible to have a pluggable video decoder for Firefox for the HTML5 Video tag so you can hook up your own solutions. That might solve the issue for everyone.
It would have solved the issue for everyone. The problem is that Mozilla explicitly refuses to do that for ideological reasons! They don't want to give users freedom of choice, if that freedom may lead them to choosing "unfree" codecs.
(note also that most claimed technical problems with DirectShow in that blog post are pure FUD)
In fact, there already is a patch to enable GStreamer support for video codecs, but so far it's only been accepted for Fennec, not for mainline desktop Firefox.
-
Direct2D and DirectWrite (GPU Acceleration)
Firefox already has support for these in the 3.7 prerelease builds. All of the IE9 tests that showcase the benefits of these two API's worked amazingly on my D2D+DW enabled Firefox, while Chrome fell flat. If you're interested in enabling it then see this: http://forums.mozillazine.org/viewtopic.php?f=23&t=1775755
-
Re:H.264
-
Re:Avant browser == front-end for IE
SeaMonkey can't be on the ballot because there is a one browser per vendor policy, and Mozilla counts as SeaMonkey's vendor. Netscape is out because AOL doesn't actively offer it anymore. Stupid policies, but there you have it.
http://weblogs.mozillazine.org/seamonkey/archives/2010/03/see_no_monkey_d.html
-
Re:GPU acceleration and Opera
Is it not possible to have the browser use an external codec while still controlling rendering of controls and such? Like can Firefox theoretically rely on the x264 library from VLC while still controlling how it looks?
Well, that depends on what you mean.
I may have misinterpreted your "Why not just kick H264 over to a media player (VLC/Quicktime/WMP)" statement; I was thinking you were suggesting that the browser just use a plugin from the appropriate media player. In that case, the browser probably wouldn't have control unless it pulled some pretty elaborate tricks.
However, there are frameworks where the OS itself provides codec support and programs can just harness what's available, and Mozilla certainly could do that. (See here for a discussion of why Firefox won't do this, at least in the immediate term. If the dust from the codec war settles on the side of H.264 you'll probably see them change their decision, but that won't happen for a while.) However, in this case it wouldn't really be using the rendering library from VLC or whatever.
As far as scraping... yeah... I'm not sure I care. If you put a copyrighted GIF on your site, it's not totally easy to keep people from downloading it and violating the copyright. That doesn't make it a good idea to render all GIF files in Flash
No, but if changing to HTML5 would mean that it became rather easier to scrape the URL, it does mean that there would be plenty of sites that wouldn't make the switch. From their perspective, HTML5 wouldn't really offer any benefit, and Flash is going to be sticking around for a long time more even if this codec issue was solved overnight and all browsers immediately supported HTML5, so a lot of them would choose to lose the few visitors who would refuse to run the Flash plugin. That's my speculation anyway.
-
Re:GPU acceleration and Opera
In the mean time, Mozilla has stated that they're unable to ship H.264 as part of Firefox. H.264 has patent and licensing issues associated with it.
Your choices are still 1) create content once for a ubiquitous platform available absolutely everywhere except Apple embedded devices (where Apple chooses for you that you don't have access to it), or 2) create content multiple times in multiple formats, falling back on browser sniffing and other skulduggery, plus having to test on a variety of different platforms, then going ahead and creating the #1 version anyway since there are still people you can't reach without this no matter how hard you try.
HTML5 is the right direction. But it is a long, long way from mature. There isn't a single ubiquitous codec even when your users support the fledgling standard otherwise. Until then, Flash is still the right choice for all but technical purists, both for video, and for absolutely everything else Flash offers (including feature domain HTML5 doesn't cover even in draft).
-
Re:standardize a codec for html5 or die trying
This is an issue for browsers like Firefox.
"Only" because Firefox refuses to use something like DirectShow to use whatever codecs are available on the system.
See here for why; they aren't necessarily bad reasons, but changing their opinion on this matter would largely solve the H.264 codec patent issue as far as Firefox is concerned.
-
Apple and patents...
What's new here is that Apple is possibly thinking of making this a standard while owning critical patents on it, then after this is widespread (if it ever happens) crackdown on competition using its patents.
Apple is becoming more evil lately, see the recent attempt to shut down competition on smartphones from HTC using completely trivial software patents (the original article is from LWN, I highly suggest getting a subscription there).
Sounds familiar? Remember GIF? MP3? h.264? Yeah, I know, this last reference will get me modded as troll.