Firefox 5 forces update of CopperCube and CopperLicht

Posted on:June 23 2011

Mozilla just released a new version of their browser - Firefox 5. Just three months after they released the latest major version, because they think it is a good idea to do the same brainless version number increments as Google Chrome does. Maybe they start using build numers as their marketing version numbers soon.
Anyway, Mozilla also included a major change to their WebGL implementation: Firefox no longer loads textures from other domains. Also, it refuses to load textures from the local disk which is quite bugging when you are developing a WebGL app on your disk. People using my software CopperCube or CopperLicht would think this is a bug when testing out their 3D apps created with the editor for example. The scene would appear, but everything would look black, because no textures could be loaded.
So now I released version 2.5.4 of CopperCube and version 1.3.7 of CopperLicht, where I am detecting this situation and writing a message in there, hoping the user reads this and sees that the problem is in fact Firefox.

BTW: if you come across the same problem, simply do this: Enter about:config in the Firefox adress bar, and set the setting security.fileuri.strict_origin_policy to false. Your WebGL stuff then will start working again, also locally.

Comments:

i dont think the more frequent major versions are just marketing nonsense. they allow major changes to occur more frequently. sounds like a good idea to me. who'd want to work on major changes for an open source project when they know it will be years before there's a chance that users get to use it?

Matthias

Quote
2011-06-23 17:06:00

Naming the version 4.1 wouldn't change the release date.
From Firefox 3 to 4, there were huge changes in layout and rendering, that is a major update.
What are the major changes from 4 to 5? If all 3-4 months bring along a new major version, we will see FF 23 in no time... :)

bluecat

Quote
2011-06-24 01:00:00

Well actually I understand the simplicism in Chrome's version numbering scheme: 14 is greater than 13, but is 3.10 greater than 3.1? Given the fact that a lot of programmers (not end-users) didn't manage to check the Windows version properly (remember any Major < 3 or Minor < 1 problems?) the easiest avoidance strategy is using just a single monotonically increasing number sequence.

Agreed: Using build numbers would give the same benefits, and with one build a day and just a 16 bit build number you anyways have some ~170 years of peace. But build numbers are rather not that easy to remember, since released builds tend to have non-consecutive numbers, and larger ones as well. So assigning a simple sequential release number seems not too bad an idea, in particular when there are multiple releases per year (otherwise using the year would also work).

But more on-topic: Not loading textures from other domains by default may be a good idea, same policy as for normal IMG images would be sensible I suppose. Not loading locally saved images when displaying something from a locally stored page seems, however, stupid. But apparently they (somewhat) admit that they might be overly protective there.

xaos

Quote
2011-06-24 11:06:00

Who cares about WebGL? This is only relevant for iPhone users. Go for Flash 11, hardware accelerated 3D, combine it with peer2peer (Cirrus) and we are on the horse :)

Vox

Quote
2011-06-24 19:13:00