User Agent: Mozilla/5.0 (X11; Linux ppc64; rv:19.0) Gecko/20100101 Firefox/19.0 SeaMonkey/2.16 Build ID: 20130224111411 Steps to reproduce: View a page with a WebGL canvas, using Firefox 19 on Linux/PPC. Actual results: The wrong colours appeard. Example: gl_FragColor = vec4(0.0,1.0,1.0,1.0); results in a transparent pixel (should be cyan) gl_FragColor = vec4(1.0,0.0,1.0,1.0); results in a yellow pixel (should be purple) gl_FragColor = vec4(1.0,1.0,0.0,1.0); results in a purple pixel (should be yellow) gl_FragColor = vec4(1.0,1.0,1.0,0.5); results in a cyan pixel (should be semitransparent white) Since the order of the components have been completely reversed, this looks like an endianness issue, and I saw several places in the code which seemed to assume that gfxASurface::ImageFormatARGB32 actually meant BGRA (not necessarily true, since it's supposed to use native endianness). Expected results: The actual colours requested by the fragment shader should have been displayed.

This is a duplicate of bug 817356

ignore my previous comment

Marcus, can you still reproduce this? Can you provide a testcase or a URL to better reproduce it?

Alas, it seems like WebGL is completely broken in Firefox 23.0, all I get is "It doesn't appear your computer can support WebGL. Click here for more information." With Seamonkey 2.17.1 though my testpage http://mc.pp.se/webgl/webgltest.html seems to work correctly (cube is yellow). So maybe the actual colour bug was fixed in Firefox too, although I can't verify due to the other issue...

Seamonkey 2.20 also displays correct colours.

Running your testpage on Mozilla/5.0 (Macintosh; Intel Mac OS X 10.8; rv:23.0) Gecko/20100101 Firefox/23.0 I see the yellow cube. But it should be tested on a Linux platform, too.

Um, testing on Intel doesn't really make any sense though...

Marcus, try setting webgl.force-enabled=true in about:config If I set webgl.force-enabled = true in about:config I can see the yellow cube I have tested this on ppc32 with a firefox build that is between ff28 and ff29 (ff29+ is currently broken on ppc32 ) I have also tested this with mozilla-central on a ppc64 machine. I get very poor framerates but that is what one expects with software rendering.

Hi Steve. Alas, any WebGL attempts give me a crash with ATTENTION: default value of option force_s3tc_enable overridden by environment. LLVM ERROR: Do not know how to split the result of this operator! right now. This happens both in Firefox and Seamonkey. It seems to be related to Mesa using the llvmpipe driver. It used to use DRM acceleration with my Radeon HD card, but that seems to have broken in some Mesa update... :-(

Also tried on the Mac Mini G4, which still seems to have working HW acceleration. There I get the "It doesn't appear your computer can support WebGL." message though, even with webgl.force-enabled set to true... (FF28, Ubuntu 14.04) Weird.