418.15 KB, image/png
85.89 KB, text/plain
354.14 KB, image/png
323.11 KB, image/png
705.86 KB, image/png
This is quite interesting. I am attaching an image. The original sample is: http://webglsamples.googlecode.com/hg/imagesphere/imagesphere.html I saved to the disk. Them modified the sample, local, to use images from the hosted site ( full URLs to the above domain etc ). Also changed a bit some of the sin/cos parameters so I could have a cylinder, not a sphere. Problem: Notice that the contents of my gmail inbox are blended in the middle of the images loaded from the net.
Sounds like a major security bug. But does not necessarily have to be hidden at this point, as it is most likely to be a driver bug and not to be scriptable. Investoigating ASAP.
Created attachment 509453 [details] Image of demo shows blend of picture with content from tab ( gmail inbox )
Yeah, that is why I filed this quickly. BTW when I reloaded this page the problem was gone. But it appears if you leave the page ( the tab of the DEMO ) for a while -- also confirming now it shows with the URL demo from comment #1.
Can you please go to about:support, copy to clipboard, and paste here the Graphics section.
This demo is using renderbuffers, where proper initialization is notably nontrivial. I am currently checking that we're getting it right. In other words, at this stage, it could still be our bug.
Created attachment 509531 [details] log GL calls on WebGL context (~500 first calls) Ah! No, this demo is not using renderbuffers. The calls I was seeing were our own initialization stuff, when creating a WebGL context. There isn't a single renderbuffer/framebuffer related call in this WebGL app. See attached log of all GL calls on the GL context used by this WebGL context.
So, I am still interested in what I asked for in comment 4; and I would also like you to try the following: please download a debug build of Minefield: 32bit: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-02-03-03-mozilla-central-debug/firefox-4.0b12pre.en-US.debug-mac.dmg 64bit: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2011-02-03-03-mozilla-central-debug/firefox-4.0b12pre.en-US.debug-mac64.dmg install it, open a Terminal, do export MOZ_GL_DEBUG=1 and then run Minefield (that debug build) from that Terminal. Does it make a difference? Does it crash? If it does, what's the output in the Terminal?
Info you requested: Graphics Adapter Description 0x22600,0x20400 Vendor ID 0000 Device ID 0000 Adapter RAM Adapter Drivers Driver Version Driver Date Direct2D Enabled false DirectWrite Enabled false WebGL Renderer NVIDIA Corporation -- NVIDIA GeForce 9400M OpenGL Engine -- 2.0 NVIDIA-1.5.48 GPU Accelerated Windows 3/3 OpenGL
Ok. Downloaded the 32 bit and opened the demo. The problem was ( before ) coming up after hours with the tab kept in my list of opened tabs. So I found a way now, using Mac OSX 10.5.8 here, to replicate it much faster. I am able to see the problem right away if I put my computer screen, wait Mac OS X sleep, and open the screen. Then I got a bunch of snapshot of the tabs mixed in the shading, mostly in the bottom and upper part of the cylinder ( the part where usually a shadow or light would be placed ). What is even more weird now ( attaching the image in a bit ) is that the images I have showed there are from a previous minefield session -- not the current. Notice the current I have only 3 tabs, but not gmail. But gmail still shows in there. * No Crash; * Nothing in the console that seems WebGl weird. When the page loads OpenGL vendor ('NVIDIA Corporation') recognized as: NVIDIA --- WebGL context created: 0x257a4a00 Then nothing more except a lot of WARNING: Overflowed nscoord_MAX in conversion to nscoord: file ../../dist/include/nsCoord.h, line 359 that I get when I load any new tab.
Created attachment 509770 [details] Snapshot of demo shows a cylinder with incorrect rendering Also noticed the images in there are from an old session I think. I Saw a piano web page I did access that page some time ago.
Did you do the export MOZ_GL_DEBUG=1 ? Also, here's an important question. If you actually Quit firefox, and re-run it, can you still see old pages from your previous firefox session? Or is the bug happening only within pages of the same firefox session?
Yes, I thought I got the "--- WebGL context created: 0x257a4a00" because was in export MOZ_GL_DEBUG=1. I did open from the terminal. So the images I saw were from other sessions. BTW, new information. I see pieces from a terminal. So looks like the images in there are from the desktop raw buffer, not content of other tabs. I thought it was tabs probably because I keep with firefox using most of the screen.
Created attachment 509819 [details] Another screenshot, shows images, at the top of a terminal console.
I wonder if we're somehow losing the GL context and/or textures, and GL just doesn't tell us (makecurrent doesn't seem to be failing?); we then use existing texture IDs which end up pointing to other random objects in memory. Marcio, what version of OSX are you on?
I am using Mac OSX 10.5.8. So when you run the Google demo ( http://webglsamples.googlecode.com/hg/imagesphere/imagesphere.html ) put the computer screen to sleep and open, you do not see any texture problems? Could this be simply a trouble with the Mac OSX Webgl drivers?
Oh, 10.5. Given the number of grave bugs we have with 10.5 OpenGL, especially bug 618848 and bug 622836, and now this, I think it may be safest to blacklist 10.5.
In addition, bug 593867 (the validateProgram crash) is on 10.5. Unfortunately, at least the present bug is 10.5.8, killing hopes that some 10.5.x might be all good.
OK, I kind of forgot about this. Going to blacklist 10.5.
It seems like this only happens on sleep? If so we may be able to reupload the textures when we come out from sleep.
Filed Apple bug 9129398
Today I came across a report of the same bug, this time on Mac OS 10.6.8 with a Intel GPU. http://wahlers.com.br/claus/blog/talking-about-webgl-and-security
(In reply to Jeff Muizelaar [:jrmuizel] from comment #20) > It seems like this only happens on sleep? If so we may be able to reupload > the textures when we come out from sleep. It would be nice if this were sleep specific. But we wouldn't be able to reupload WebGL textures anyway. Rather, the solution would be to lose all WebGL contexts when coming out from sleep. How do we detect that we just came out of sleep, on Mac?
Marcio: can you please try Nightly from today or later? It has a tentative work-around for this bug. Notice that since WebGL is blocked on Mac OS 10.5 you have to force-enable it (go to about:config and set webgl.force-enabled). Also, this bug has been confirmed on Mac OS 10.6 and 10.7 now, and on other GPUs. It might be affecting all Macs.
See bug 684882 (currently non public but I gave you access to it)
Today I saw this bug on Peacekeeper's dandelion test, the dandelion textures were my Dock icons. This was in a session that was running for quite some time, and the notebook possibly slept while it was running, but I'm not sure about that. Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:10.0a1) Gecko/20111028 Firefox/10.0a1 ID:20111028031044
oops... please attach about:support contents. Please try these links on this machine. Reload each of them a few times. http://alteredqualia.com/three/examples/webgl_cars.html (do you see junk in the background?) http://people.mozilla.org/~bjacob/webgltexturecubemap.html (should show just a green/black grid on a triangle) http://people.mozilla.org/~bjacob/webgltexturecubemap-flat.html (should show only a large black square area) the next time it happens, can you please: - take a screenshot - try above links - try in another browser
erm, though... my links use a 1024x1024 cube map which should be disallowed on your machine following Bug 684882... so I expect they'll just generate a WebGL error on your machine. Can you try this instead a few times: http://people.mozilla.org/~bjacob/webgltexturecubemap-flat-512.html
Created attachment 570475 [details] Screenshot of the issue happening. (In reply to Benoit Jacob [:bjacob] from comment #27) > please attach about:support contents. http://pastebin.mozilla.org/1367060 > > Please try these links on this machine. Reload each of them a few times. > > http://alteredqualia.com/three/examples/webgl_cars.html > (do you see junk in the background?) > Yes, while it's loading. See attached screenshot. Doesn't happen in Chrome stable. > http://people.mozilla.org/~bjacob/webgltexturecubemap.html > (should show just a green/black grid on a triangle) > > http://people.mozilla.org/~bjacob/webgltexturecubemap-flat.html > (should show only a large black square area) > Both work as intended.
OK. The fact that http://people.mozilla.org/~bjacob/webgltexturecubemap.html works for you means that Firefox is not using the work-around we have for Bug 684882 which we use only for Intel GPUs. Indeed your about:support shows that it _thinks_ it's using a NVIDIA card (but it could be wrong about that). I'm afraid that the graphics card is changing under our feet without us noticing. Can you please install the gfxCardStatus utility and force usage of only 1 GPU: first try forcing Intel integrated graphics, then try forcing the discrete NVIDIA chip. Can the bug still be reproduced in either case? The present bug was only for Mac OS 10.5. It should have been marked as FIXED a long time ago, as we blacklist WebGL on 10.5. If this bug turns out to be specific to the Intel GPU, please continue this conversation on Bug 684882; if this actually happens on the NVIDIA GPU, please file a new bug.
Just for reference, I saw a problem similar to this "image frame buffer from another video session showed in the "webcam" area of Web rtc infra in Chrome 23 with Mountain Lion Mac OS X. I am mentioning Chrome case here as reference on the possible problem that may still be active towards the Mac OS X side.
I would recomment that you file a Chrome bug report then; and if you can reproduce in Firefox, please file a new Mozilla bug too. At least on Mozilla side that would be a security bug report.