Last Comment Bug 701269 - WebGL / Canvas displaying uninitialized video memory.
: WebGL / Canvas displaying uninitialized video memory.
Status: RESOLVED FIXED
[sg:vector-high][qa-]
:
Product: Core
Classification: Components
Component: Canvas: WebGL (show other bugs)
: unspecified
: x86 Mac OS X
: -- normal (vote)
: mozilla11
Assigned To: Jeff Gilbert [:jgilbert]
:
: Milan Sreckovic [:milan]
Mentors:
Depends on: 705024
Blocks: 711642
  Show dependency treegraph
 
Reported: 2011-11-09 18:48 PST by Michael Bebenita [:mbx]
Modified: 2012-04-10 21:27 PDT (History)
16 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
wontfix
wontfix
+
wontfix
+
fixed
11+
fixed
unaffected


Attachments
HTML page that reproduces bug and screenshot. (106.79 KB, application/zip)
2011-11-09 18:48 PST, Michael Bebenita [:mbx]
no flags Details
HTML page that reproduces bug. (564 bytes, text/html)
2011-11-09 23:27 PST, Michael Bebenita [:mbx]
no flags Details
remove early return in ResizeOffscreenFBO that we're hitting, and that doesn't seem to make sense (827 bytes, patch)
2011-11-12 15:28 PST, Benoit Jacob [:bjacob] (mostly away)
jgilbert: review-
Details | Diff | Splinter Review
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (5.15 KB, patch)
2011-11-13 18:16 PST, Jeff Gilbert [:jgilbert]
jacob.benoit.1: review+
Details | Diff | Splinter Review
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (5.32 KB, patch)
2011-11-14 13:38 PST, Jeff Gilbert [:jgilbert]
no flags Details | Diff | Splinter Review
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (11.78 KB, patch)
2011-11-20 23:59 PST, Jeff Gilbert [:jgilbert]
jgilbert: review-
Details | Diff | Splinter Review
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (12.10 KB, patch)
2011-11-21 02:40 PST, Jeff Gilbert [:jgilbert]
no flags Details | Diff | Splinter Review
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (14.69 KB, patch)
2011-11-21 18:28 PST, Jeff Gilbert [:jgilbert]
no flags Details | Diff | Splinter Review
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (14.72 KB, patch)
2011-11-21 18:49 PST, Jeff Gilbert [:jgilbert]
jacob.benoit.1: review-
Details | Diff | Splinter Review
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (7.87 KB, patch)
2011-12-16 15:46 PST, Jeff Gilbert [:jgilbert]
jacob.benoit.1: review+
Details | Diff | Splinter Review
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (fx10) (7.46 KB, patch)
2012-01-17 12:05 PST, Jeff Gilbert [:jgilbert]
jacob.benoit.1: review+
akeybl: approval‑mozilla‑beta-
Details | Diff | Splinter Review
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (esr10) (7.46 KB, patch)
2012-02-28 18:14 PST, Jeff Gilbert [:jgilbert]
jacob.benoit.1: review+
lukasblakk+bugs: approval‑mozilla‑esr10+
Details | Diff | Splinter Review

Description Michael Bebenita [:mbx] 2011-11-09 18:48:26 PST
Created attachment 573407 [details]
HTML page that reproduces bug and screenshot.

Setting the canvas width and height properties AFTER you get an webgl context can lead to reading of arbitrary video data, desktop images, other tabs, etc. This seems to occur on MacBook Airs, and not on MacBook Pros. This occurs in Firefox 6.0.2, as well as Nightly.

Machine
=======

  Model Name:	MacBook Air
  Model Identifier:	MacBookAir4,2
  Processor Name:	Intel Core i7
  Processor Speed:	1.8 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	4 MB
  Memory:	4 GB
  Boot ROM Version:	MBA41.0077.B0E
  SMC Version (system):	1.73f63

about:support
=============
 
Adapter Description: 0x24300,0x20400
WebGL Renderer: Intel Inc. -- Intel HD Graphics 3000 OpenGL Engine -- 2.1 APPLE-7.12.9GPU 
Accelerated Windows: 1/1 OpenGL
Comment 1 Andreas Gal :gal 2011-11-09 23:24:31 PST
This seems to occur only on some hardware. Setting sg:high for now (information leak).
Comment 2 Michael Bebenita [:mbx] 2011-11-09 23:27:47 PST
Created attachment 573432 [details]
HTML page that reproduces bug.
Comment 3 Benoit Jacob [:bjacob] (mostly away) 2011-11-09 23:37:24 PST
This is not the same bug as bug 684882, but that one also was specific to Intel GPUs on Mac OSX, with similar consequences.
Comment 4 Benoit Jacob [:bjacob] (mostly away) 2011-11-09 23:38:56 PST
The reason why it only happens on MacBook Airs is that we use the discrete (non-Intel) GPU for WebGL when there is one. MacBook Airs are special in that they only have Intel integrated graphics.

What is your Mac OS X version?
Comment 5 Michael Bebenita [:mbx] 2011-11-10 08:23:18 PST
I'm running, Mac OS X Lion 10.7.2 (11C74)
Comment 6 Benoit Jacob [:bjacob] (mostly away) 2011-11-10 08:42:33 PST
Does the problem go away if you set webgl.msaa-level=0 ?   (in about:config)

Does it go away if you set layers.acceleration.disabled=true and restart Firefox?

Is the size 512 important in your testcase? Is there a minimal size under which the problem doesn't happen?

Note that this should be reproducible on other Macs by using the gfxCardStatus utility to force Firefox to use Intel integrated graphics.
Comment 7 Michael Bebenita [:mbx] 2011-11-10 09:52:30 PST
I added webgl.msaa-level = 0 to about:config since it wasn't already there and the problem persists.

I set layers.acceleration.disabled=true and restarted Firefox and the problem still persists.

512 is not that important, the lowest I was able to set it, and yet reproduce the bug was 300. As you increase the size you can see more. I'm guessing that when using larger sizes it's more likely to encounter stretches of non zero memory.
Comment 8 Benoit Jacob [:bjacob] (mostly away) 2011-11-10 11:13:02 PST
Chrome doesn't seem to suffer from this bug. It's possible that it might be a bug on our side. investigating.
Comment 9 Benoit Jacob [:bjacob] (mostly away) 2011-11-10 12:09:14 PST
The bug is Mac-specific (but could well be a bug in our code).

The testcase results in GLContext::ResizeOffscreenFBO being called 3 times (yes, we need to make that lazy). We check on Jeff M's Mac and it didn't call ClearSafely() everytime.

But here on Linux, I do get ClearSafely called everytime by ResizeOffscreenFBO.

We need to step though ResizeOffscreenFBO carefully on a Mac to figure where we're returning early, before the ClearSafely call.

At a more meta-level, we need to make this code less prone to forgetting to ClearSafely.
Comment 10 Andreas Gal :gal 2011-11-10 12:25:45 PST
Can RAII help here?
Comment 11 Benoit Jacob [:bjacob] (mostly away) 2011-11-10 13:06:31 PST
(In reply to Andreas Gal :gal from comment #10)
> Can RAII help here?

Probably, yes, since the problem is that we need to ensure that ClearSafely gets called even if we return early.

I would still like to understand where exactly things go wrong on Mac.
Comment 12 Jeff Muizelaar [:jrmuizel] 2011-11-12 14:56:47 PST
I can't reproduce this on a Nightly anymore. We should get a range on when it was fixed.
Comment 13 Andreas Gal :gal 2011-11-12 14:59:21 PST
Michael, does this still happen for you with a nightly?
Comment 14 Jeff Muizelaar [:jrmuizel] 2011-11-12 15:07:54 PST
This was "fixed" because antialaising is now used on OS X. Forcing msaa-level to 0 causes the bug to show up again.
Comment 15 Jeff Muizelaar [:jrmuizel] 2011-11-12 15:09:26 PST
We don't call ClearSafely in ResizeOffscreenFBO because we take the following condition:

    if (!useDrawMSFBO && !aUseReadFBO)
        return true;
Comment 16 Benoit Jacob [:bjacob] (mostly away) 2011-11-12 15:28:50 PST
Created attachment 574094 [details] [diff] [review]
remove early return in ResizeOffscreenFBO that we're hitting, and that doesn't seem to make sense

I don't understand that early return. Even if we don't have a MS draw FBO and don't have a read FBO, we still have a non-MS draw FBO to resize. So why return early here?

This is definitely the early return that Jeff was hitting. He had to set msaa-level=0 to be able to reproduce since AA has been turned on on Mac.

Side question: I couldn't reproduce this on Linux as there, aUseReadFBO is true (while it's false on Mac with AA disabled). Why is that?
Comment 17 Jeff Muizelaar [:jrmuizel] 2011-11-12 15:57:26 PST
(In reply to Benoit Jacob [:bjacob] from comment #16)
> Created attachment 574094 [details] [diff] [review] [diff] [details] [review]
> remove early return in ResizeOffscreenFBO that we're hitting, and that
> doesn't seem to make sense
> 
> I don't understand that early return. Even if we don't have a MS draw FBO
> and don't have a read FBO, we still have a non-MS draw FBO to resize. So why
> return early here?
> 
> This is definitely the early return that Jeff was hitting. He had to set
> msaa-level=0 to be able to reproduce since AA has been turned on on Mac.
> 
> Side question: I couldn't reproduce this on Linux as there, aUseReadFBO is
> true (while it's false on Mac with AA disabled). Why is that?

This patch fixes it for me.
Comment 18 Andreas Gal :gal 2011-11-12 16:36:40 PST
Thanks for the quick fix guys.
Comment 19 Jeff Gilbert [:jgilbert] 2011-11-13 15:37:34 PST
This isn't the proper fix, since ResizeOffscreenFBO wasn't even called for all paths until AA hit. For paths using backing PBuffers, for example, we never called it, so we had to make sure we were clearing the buffer elsewhere.

It looks like we are just not clearing the buffer on Mac w/PBuffers.
Comment 20 Jeff Gilbert [:jgilbert] 2011-11-13 18:14:22 PST
Comment on attachment 574094 [details] [diff] [review]
remove early return in ResizeOffscreenFBO that we're hitting, and that doesn't seem to make sense

Uploading a new fix shortly.
Comment 21 Jeff Gilbert [:jgilbert] 2011-11-13 18:16:41 PST
Created attachment 574213 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly

Try: https://tbpl.mozilla.org/?tree=Try&rev=de8f0e15f875
Comment 22 Jeff Gilbert [:jgilbert] 2011-11-14 03:03:05 PST
Looks like it passes try.
Can someone on Mac replicate this bug before applying the fix, but not after?
Comment 23 Michael Bebenita [:mbx] 2011-11-14 10:49:52 PST
I updated to the latest Nightly (11.0a1 (2011-11-14)) and the bug is still there.
Comment 24 Michael Bebenita [:mbx] 2011-11-14 11:25:44 PST
I also tried it on this build ftp://ftp.mozilla.org/pub/firefox/try-builds/jgilbert@mozilla.com-de8f0e15f875/try-macosx64/firefox-11.0a1.en-US.mac.dmg and it still fails.
Comment 25 Jeff Gilbert [:jgilbert] 2011-11-14 13:38:22 PST
Created attachment 574403 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly

Added MakeCurrent call before clearing after resize.
Comment 26 Jeff Gilbert [:jgilbert] 2011-11-14 19:16:56 PST
This is fixed if we use the hidden pref cgl.prefer-fbo set to true. (default is false) This must be a problem with the PBuffers path in CGL.
Comment 27 Jeff Gilbert [:jgilbert] 2011-11-15 00:28:56 PST
What's the first version which this fails on?
We can simply fix 10 by using cgl.prefer-fbo until we can track down the elusive problem.
Comment 28 Benoit Jacob [:bjacob] (mostly away) 2011-11-15 04:51:22 PST
(In reply to Jeff Gilbert [:jgilbert] from comment #27)
> What's the first version which this fails on?
> We can simply fix 10 by using cgl.prefer-fbo until we can track down the
> elusive problem.

What's your feeling about this: is the CGL/FBO path in good enough shape for this despite not having been default until now? if we switch, we should do it ASAP to maximize testing.
Comment 29 Jeff Gilbert [:jgilbert] 2011-11-15 18:53:35 PST
I do not know. Can someone with a mac compare mochitest outputs with cgl.prefer-fbo? This is currently a pretty big problem. It may be worth switching paths until this is solved, even if we take a small conformance hit.
Comment 30 Benoit Jacob [:bjacob] (mostly away) 2011-11-16 04:56:53 PST
Just make a tryserver push?
Comment 31 Gregor Wagner [:gwagner] 2011-11-18 11:36:19 PST
I also got this behavior with todays nightly on my MacBook Pro.
This website shows me uninitialized data at the beginning:
http://alteredqualia.com/three/examples/webgl_terrain_dynamic.html
Comment 32 Benoit Jacob [:bjacob] (mostly away) 2011-11-18 14:02:47 PST
According to Jeff M in comment 17, my patch (now r-'d and obsoleted) fixed (the effects of) this bug even if it wasn't the correct solution. Shouldn't we just take it? It just removes 2 lines that we agreed were wrong. So actually I'm not sure i understand the r- on it.
Comment 33 Jeff Gilbert [:jgilbert] 2011-11-19 00:09:29 PST
The code after the early exit relies upon the assumption that the conditions of the early exit are false. That is, the code is not designed to work without the early-out. Resize code in GLContext should not be responsible for clearing the buffers, because that's only needed by WebGL, and actually easier to assure if we deliberately clear the buffer in WebGL.

I think the reason the deguarantee patch was still failing was because the read FBO isn't blitted to before we use it as a texture for drawing. Either ClearSafely() should force-blit the FBOs, or layers code must guarantee that it will blit the buffers before using the texture. The latter seems the more proper solution, to me.
Comment 34 Benoit Jacob [:bjacob] (mostly away) 2011-11-19 08:49:45 PST
OK. Please continue driving this i.e. talk with Layers people as needed; we need to have this bug fixed ASAP.
Comment 35 Robert O'Callahan (:roc) (email my personal email if necessary) 2011-11-20 15:43:24 PST
Matt Woodrow's out most of this week. Who else knows GLContext and layers?

Is there a GLContext method the layer system needs to call before every render of a WebGL CanvasLayer? What is it? E.g., what is BasicCanvasLayer::UpdateSurface not doing that it should be doing?
Comment 36 Jeff Gilbert [:jgilbert] 2011-11-20 23:59:47 PST
Created attachment 575817 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly

Updated to assure that buffers are cleared before using the texture by adding GLContext::ReadyOffscreenTexture.

Testing via try at: https://tbpl.mozilla.org/?tree=Try&rev=f699ee432c35

I will be able to run tests/debug locally on mac and linux tomorrow.
Comment 37 Jeff Gilbert [:jgilbert] 2011-11-21 02:14:05 PST
Comment on attachment 575817 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly

Assumes that glFlush is sufficient to sync buffers across contexts.
Comment 38 Jeff Gilbert [:jgilbert] 2011-11-21 02:40:20 PST
Created attachment 575827 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly

Updated to use OpenGL spec-guaranteed glFinish for syncing textures between GLContext and Layers in D3D10 and OGL.
Comment 39 Jeff Gilbert [:jgilbert] 2011-11-21 02:41:29 PST
New try run: https://tbpl.mozilla.org/?tree=Try&rev=f481ecdb6027
Comment 40 Jeff Gilbert [:jgilbert] 2011-11-21 15:41:15 PST
I'll also note here that I cannot reproduce this on my Mac:
Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0a1) Gecko/20111121 Firefox/11.0a1
ATI Technologies Inc. -- AMD Radeon HD 6630M OpenGL Engine -- 2.1 ATI-7.12.9
Comment 42 Jeff Gilbert [:jgilbert] 2011-11-21 16:26:39 PST
It must be using a path I'm not expecting, investigating...
Comment 43 Jeff Gilbert [:jgilbert] 2011-11-21 17:51:53 PST
Does it also replicate without errors on the debug builds from that try batch?
Comment 44 Michael Bebenita [:mbx] 2011-11-21 17:57:14 PST
Same behavior in the debug builds.
Comment 45 Jeff Gilbert [:jgilbert] 2011-11-21 18:26:40 PST
Ok, until I can replicate this and fix it properly, we should probably hack around this and just manually blit the buffers in WebGLContext::SetDimensions.

Note that there still exists a bug where we are not correctly resolving the GLContext before drawing it out with OGL Layers.
Comment 46 Jeff Gilbert [:jgilbert] 2011-11-21 18:28:36 PST
Created attachment 576058 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly

https://tbpl.mozilla.org/?tree=Try&rev=5fca6dc7a41c
Comment 47 Jeff Gilbert [:jgilbert] 2011-11-21 18:49:53 PST
Created attachment 576063 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly

Fixed forgetting to force the resolve after the blit.

https://tbpl.mozilla.org/?tree=Try&rev=6089a0a4ff7b
Comment 48 Jeff Gilbert [:jgilbert] 2011-11-23 16:53:53 PST
While this should be fixed anyways, bug 702058 switches to using FBOs instead of PBuffers on Mac, which should hide this bug.
Comment 49 Benoit Jacob [:bjacob] (mostly away) 2011-11-23 17:31:37 PST
Comment on attachment 576063 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly

Review of attachment 576063 [details] [diff] [review]:
-----------------------------------------------------------------

Just some nits, need some explanations.

::: content/canvas/src/WebGLContext.cpp
@@ +545,5 @@
>          // everything's good, we're done here
>          mWidth = gl->OffscreenActualSize().width;
>          mHeight = gl->OffscreenActualSize().height;
> +
> +        gl->ClearSafely();

Since we must not forget to call ClearSafely in SetDimensions, and I don't see a very good way to ensure it's always called (since it should not be called in error cases), I would really, really like a unit test (can take the testcase of this bug as a starting point).

::: gfx/gl/GLContext.cpp
@@ +1387,1 @@
>          fViewport(viewport[0], viewport[1], viewport[2], viewport[3]);

I don't get that. Why are we still playing at all with the viewport here? I thought that was only needed a long time ago when ClearSafely didn't take care of it. It now does, so this viewport business should have been useless for a while. Moreover I don't understand why firstTime matters here.

::: gfx/gl/GLContext.h
@@ +1010,5 @@
>  
> +    // Before reads from offscreen texture
> +    // Resolve contents in this context, before we resume work with the contents on 'other' context
> +    // If other is null, block until new commands will only be executed after the resolve. (Usually via glFinish)
> +    void ResolveBeforeResumingOther(GLContext* other = nsnull) {

As discussed, I would mimic the ARB_sync API here rather than coming up with a custom function name. Ideally it would be neat if we could implement the ARB_sync API with a fallback to using glFinish (and maybe, later, some mutex locking) when ARB_sync is not available.
Comment 50 Michael Bebenita [:mbx] 2011-12-15 13:48:38 PST
Although I cannot reproduce it, it seems that a similar problem persists when waking up the laptop from sleep mode. I'm guessing it may have something to do with a loss of the GL context.
Comment 51 Jeff Gilbert [:jgilbert] 2011-12-16 15:46:10 PST
Created attachment 582419 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly
Comment 53 Jeff Gilbert [:jgilbert] 2011-12-19 15:51:39 PST
(In reply to Michael Bebenita from comment #50)
> Although I cannot reproduce it, it seems that a similar problem persists
> when waking up the laptop from sleep mode. I'm guessing it may have
> something to do with a loss of the GL context.

Are you seeing this only in WebGL contexts, or for the whole browser?
Comment 54 Michael Bebenita [:mbx] 2011-12-19 17:17:49 PST
(In reply to Jeff Gilbert [:jgilbert] from comment #53)
> (In reply to Michael Bebenita from comment #50)
> > Although I cannot reproduce it, it seems that a similar problem persists
> > when waking up the laptop from sleep mode. I'm guessing it may have
> > something to do with a loss of the GL context.
> 
> Are you seeing this only in WebGL contexts, or for the whole browser?

It was only in the WebGL context.
Comment 55 Daniel Veditz [:dveditz] 2011-12-20 07:20:20 PST
inbound/m-c merge by Ed Moreley
https://hg.mozilla.org/mozilla-central/rev/91141088eb7d
Comment 56 Daniel Veditz [:dveditz] 2011-12-20 07:33:14 PST
From a quick read this sounds like a Mac OS/driver bug we're working around rather than a bug in our code per se. If that's wrong please change the whiteboard back to [sg:high].

Please create a patch to land on Firefox 10 and request approval-mozilla-beta, or attach the request to the existing patch if it works land as-is.
Comment 57 Jeff Gilbert [:jgilbert] 2012-01-17 12:05:15 PST
Created attachment 589258 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (fx10)

Backport to Fx10.
Comment 58 Jeff Gilbert [:jgilbert] 2012-01-17 12:45:45 PST
Comment on attachment 589258 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (fx10)

[Approval Request Comment]
Regression caused by (bug #): This bug.
User impact if declined: Security concerns noted above.
Testing completed (on m-c, etc.): Was landed on MC in Fx11, now in Aurora.
Risk to taking this patch (and alternatives if risky): If there is anyone relying on GLContext resizes clearing its buffers (besides WebGL, as fixed in this patch), they may receive uninitialized data instead of cleared buffers.
Comment 59 Jeff Gilbert [:jgilbert] 2012-01-17 12:49:37 PST
Try attempt here:
https://tbpl.mozilla.org/?tree=Try&rev=b60e9f97915f

Passing reftests, failing(?) talos, burning on android.
Comment 60 Alex Keybl [:akeybl] 2012-01-17 15:02:37 PST
Comment on attachment 589258 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (fx10)

[Triage Comment]
Please re-set approval-mozilla-beta flag once try builds are in order and this is ready to land.
Comment 61 Jeff Gilbert [:jgilbert] 2012-01-17 21:31:18 PST
Null try run from beta:
https://tbpl.mozilla.org/?tree=Try&rev=a43849b2a5f0

Preliminarily indicates that fails encountered on previous try build were to be expected when trying from beta.

Android appears to be burning because the makefile/mozconfig requirements changed. Talos appears to be failing because it's hitting a 404 when requesting 'http://hg.mozilla.org/try/raw-file/b60e9f97915f/testing/talos/talos.json'. 

I can spend time trying to fix these to get a clean try run, but effectively the same code has passed try and landed in Fx11. Is it inviable to land it on Beta while being prepared to back it out immediately?
Comment 62 Geo Mealer [:geo] -- This account is inactive after 2015-07-07 2012-02-10 11:13:41 PST
Having problems reproducing original using identical Macbook Air with 2011-11-09 Nightly build with the included testcase.

Info:

Build identifier: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.7; rv:11.0a1) Gecko/20111109 Firefox/11.0a1

Machine:

  Model Name:	MacBook Air
  Model Identifier:	MacBookAir4,2
  Processor Name:	Intel Core i7
  Processor Speed:	1.8 GHz
  Number of Processors:	1
  Total Number of Cores:	2
  L2 Cache (per Core):	256 KB
  L3 Cache:	4 MB
  Memory:	4 GB
  Boot ROM Version:	MBA41.0077.B0E
  SMC Version (system):	1.73f63

Display:

  Chipset Model:	Intel HD Graphics 3000
  Type:	GPU
  Bus:	Built-In
  VRAM (Total):	384 MB
  Vendor:	Intel (0x8086)
  Device ID:	0x0116
  Revision ID:	0x0009

about:support:

Vendor ID: 8086
Device ID: 0116
WebGL Renderer: Intel Inc. -- Intel HD Graphics 3000 OpenGL Engine -- 2.1 APPLE-7.14.5GPU 
Accelerated Windows: 1/1 OpenGL

Looks identical, aside from the renderer. This is Lion 10.7.2, same as mentioned in comment 5.

Since I can't repro original, can't verify fix yet.
Comment 63 Lukas Blakk [:lsblakk] use ?needinfo 2012-02-23 16:46:39 PST
[Triage comment]

This bug is being tracked for landing on ESR branch.  Please land patches on http://hg.mozilla.org/releases/mozilla-esr10/by Thursday March 1, 2012 in order to be ready for go-to-build on Friday March 2, 2012.

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more information.
Comment 64 Lukas Blakk [:lsblakk] use ?needinfo 2012-02-28 10:40:02 PST
[Triage comment]
Confirmed with dveditz that esr10 is affected by this bug and requires this patch to go to build - can someone please land today or tomorrow?  Let me know if there are any concerns we should be aware of.
Comment 65 Jeff Gilbert [:jgilbert] 2012-02-28 18:14:10 PST
Created attachment 601483 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (esr10)

Original patch applied (almost) cleanly to esr10, minus one comment line. (which conflicted)
Comment 66 Lukas Blakk [:lsblakk] use ?needinfo 2012-02-29 11:21:11 PST
Comment on attachment 601483 [details] [diff] [review]
Deguarantee ResizeOffscreenFBO clearing its buffers, and adding clears in WebGLContext accordingly (esr10)

[Triage Comment]
Nomination for esr10 approved, please land this today if possible so we're ready to go to build on Friday. Thank you.
Comment 67 Jeff Gilbert [:jgilbert] 2012-02-29 16:09:36 PST
ESR10:
https://hg.mozilla.org/releases/mozilla-esr10/rev/349408792301
Comment 68 juan becerra [:juanb] 2012-03-06 12:31:28 PST
I haven't been able to reproduce the original problem in order to verify this bug fix. Geo, could you give it another try when you get a chance?
Comment 69 Geo Mealer [:geo] -- This account is inactive after 2015-07-07 2012-03-06 17:33:45 PST
I'll bring my Air tomorrow and will try again.
Comment 70 Anthony Hughes (:ashughes) [GFX][QA][Mentor] 2012-03-08 13:21:11 PST
QA is unable to verify this fix because we are unable to reproduce the original issue, even with an identical test environment. If someone is able to reproduce this issue, please verify the fix in Firefox 11.0b6 and 10.0.3esr.

Thanks

Note You need to log in before you can comment on or make changes to this bug.