1. Open https://www.mozilla.org/en-US/firefox/desktop/ 2. Scroll down 3. Enjoy the hang for a few seconds. 4. Enjoy the white windows with white tabs It also occurs rarely in some odd cases, but STR is hard to get... When it occurs the only tab content is white or frozen and when you swap to another tab and the content is still frozen, but you still can see that tab title is changed on START bar when you swap tabs. Setting hangmonitor.timeout to 1 doesn't help and doesn't generate any report.

Maybe it's related to not fixed completely bug #1043426 and bug #1044129

I forgot to add that browser content freeze mostly when you open a new tab link or use "Search keyword" feature The new tab isn't shown, you need to minimize and next maximize the whole window to unfreeze the browser (it doesn't work for STF as it's "hard" content freeze)

:Virtual, you're still getting this? Unfortunately I do not experience this on my laptop (only on my desktop >200km away). There's a user at mozillazine reporting those issued with earlier builds of 33.0b, where bug 1044129 was just uplifted to yesterday. So, assuming we are right about bug 1043426 introducing that behavior (we're not crashing anymore, but I assume instead freezing the content), here are the changesets introduced by that bug. If this is still troubling you, you could try finding if one of those is the regressing changeset. https://hg.mozilla.org/mozilla-central/rev/0bc9fd5d0476 https://hg.mozilla.org/mozilla-central/rev/d7e3d485cd8d

I was also facing this problem, but since few builds seems to be fixed on my side.

@ Johannes Pfrang [:johnp] - yes, I can still reproduce it on latest Firefox Nightly 35.0a1 (2014-09-22) and in a few days I will try to find a regression range

Does this solve itself if you move your mouse around over the Firefox window?

Nope, it not help, but I done some tests as I still don't have time to find the regression range. These are my observations (look especially on a 'new' crash with layers.offmainthreadcomposition.enabled=false [Direct3D 10, no OMTC] STR: 1. Open https://www.mozilla.org/en-US/firefox/desktop/ 2. Scroll to the bottom of the page 3. Scroll to the top of the page in various settings this happens: GPU Accelerated Windows - Direct3D 11 (OMTC) more info: all Firefox windows are whole in white GPU Accelerated Windows - Direct3D 10 layers.offmainthreadcomposition.enabled = false https://crash-stats.mozilla.com/report/index/80b080fa-e262-466d-8aef-816952140929 https://crash-stats.mozilla.com/report/index/22f73549-658d-42ae-bc45-878cd2140929 more info: crash GPU Accelerated Windows - Direct3D 9 (OMTC) layers.prefer-d3d9 = true more info: no crash, only these errors in about support in Graphics section under AzureSkiaAccelerated: "CompositorD3D9::CreateRenderTargetFromSource: Failed to update texture Error code: 2289436780" GPU Accelerated Windows - Direct3D 9 layers.offmainthreadcomposition.enabled = false layers.prefer-d3d9 = true https://crash-stats.mozilla.com/report/index/bfccf626-95c4-47cb-83b6-d08632140929 https://crash-stats.mozilla.com/report/index/ccf5eb8e-32c0-4899-8019-c32aa2140929 https://crash-stats.mozilla.com/report/index/dd3eddbc-45d0-4fbc-b112-adf8c2140929 https://crash-stats.mozilla.com/report/index/ec2c4e9a-9062-4947-9df8-64d4c2140929 https://crash-stats.mozilla.com/report/index/c667cf2e-552a-48fc-b39a-7f6682140929 more info: no crash and looks like it's bug #1036742 GPU Accelerated Windows - Basic layers.offmainthreadcomposition.enabled = false layers.prefer-opengl = true more info: no crash, minimaze/maximize/close buttons flickers on scrolling GPU Accelerated Windows - OpenGL (OMTC) layers.prefer-opengl = true https://crash-stats.mozilla.com/report/index/811c77fb-756b-486f-bf89-4d2232140929 more info: whole browser window are in small artifacts on borders, web content is moved oddly - when you want to select some link etc. you need to move your mouse above or under the link some pixels as it won't work GPU Accelerated Windows - Basic (OMTC) gfx.direct2d.disabled = true more info: no crash, no artifacts GPU Accelerated Windows - Basic gfx.direct2d.disabled = true layers.offmainthreadcomposition.enabled = false more info: no crash, minimaze/maximize/close buttons flickers on scrolling

Nical, does this look familiar at all? The OMTC-off crashes are mainly interesting for more diagnosis: D3D10/OMTC-off crash at mozilla::gfx::GetCairoSurfaceForSourceSurface (null aSurface) D3D9/OMTC-off crash at http://hg.mozilla.org/mozilla-central/annotate/9d66436af432/gfx/layers/d3d9/PaintedLayerD3D9.cpp#l462 NS_RUNTIMEABORT("Reference mD3D9ThebesSurface must be released by caller of Begin() before calling End()"); OMTC with no acceleration is ok, so this is presumably something specific to the accelerated setup. Are there logs? Virtual, you might get some interesting warnings or error message from a nightly debug build: http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-09-30-mozilla-central-debug/

I haven't worked with the non-OMTC D3D layers (which is an entirely separate implementation from OMTC), so nothing familiar here. hg blame points to Jeff, so I am forwarding the needinfo. That said, if OMTC sticks on Windows all of this code is going to be removed (just like we removed the non-OMTC GL layers implementations right after OMTC shipped on Mac).

That still leaves the original bug here where the screen is all white with OMTC+D2D...

I just copied the assert from the code above by bgirard....

What's the question? In Begin we lock rect, take the bits around it. In End we unlock. We shouldn't holding the surface after that point since we've unlocked the bits. Actually we shouldn't be using the bit in the surface, The aim of this check is to catch the error in the nearby End and not later when we try to use a AddRef surface elsewhere. If we have a good reason to keep a reference but know we wont touch the bits then this assert can go.

(In reply to Benjamin Smedberg [:bsmedberg] from comment #8) > Virtual, you might get some interesting warnings or error message from a > nightly debug build: > http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-09-30-mozilla- > central-debug/ These are my next observations with build http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/2014-09-30-mozilla-central-debug/ and it console logger (all add-on and plug-ins were disabled to not bloat the log), but this console logger is in some way bugged as it closed itself when crash happen, so I can't get all logs properly when crash occur and most of it crashlogger didn't works in debug build. Also no any signifficant Errors and Messager in Error Conole related to this, only website Warnings. STR: 1. Open https://www.mozilla.org/en-US/firefox/desktop/ 2. Scroll to the bottom of the page 3. Scroll to the top of the page in various settings this happens: GPU Accelerated Windows - Direct3D 11 (OMTC) more info: all Firefox windows are whole in white GPU Accelerated Windows - Direct3D 10 layers.offmainthreadcomposition.enabled = false more info: crash GPU Accelerated Windows - Direct3D 9 (OMTC) layers.prefer-d3d9 = true more info: no crash and no these errors in about support in Graphics section under AzureSkiaAccelerated: "CompositorD3D9::CreateRenderTargetFromSource: Failed to update texture Error code: 2289436780" which are seen in non-debug build GPU Accelerated Windows - Direct3D 9 layers.offmainthreadcomposition.enabled = false layers.prefer-d3d9 = true more info: crash on start (it's bug #1036742) GPU Accelerated Windows - Basic layers.offmainthreadcomposition.enabled = false layers.prefer-opengl = true more info: no crash, minimaze/maximize/close buttons flickers on scrolling GPU Accelerated Windows - OpenGL (OMTC) layers.prefer-opengl = true more info: sometimes crash, some fonts are blurry, whole browser window are in small artifacts on borders, web content is moved oddly - when you want to select some link etc. you need to move your mouse above or under the link some pixels as it won't work GPU Accelerated Windows - Basic (OMTC) gfx.direct2d.disabled = true layers.acceleration.disabled = true more info: hang, no crash, no artifacts GPU Accelerated Windows - Basic gfx.direct2d.disabled = true layers.acceleration.disabled = true layers.offmainthreadcomposition.enabled = false more info: no crash, minimaze/maximize/close buttons flickers on scrolling

I'm not sure if I also set layers.acceleration.disabled = true

I'm not sure if I also set layers.acceleration.disabled = true

Again these are my observations with normal build, as I reset it to make sure that result still are the same. The only difference is that with only layers.offmainthreadcomposition.enabled = false (Direct3D 10) Firefox isn't crashing anymore Also no any significant Errors and Messages in Error Console related to this, only website Warnings. STR: 1. Open https://www.mozilla.org/en-US/firefox/desktop/ 2. Scroll to the bottom of the page 3. Scroll to the top of the page in various settings this happens: ================================================ GPU Accelerated Windows - Direct3D 11 (OMTC) windowLayerManagerRemote - true AzureCanvasBackend - direct2d AzureContentBackend - direct2d 1.1 AzureFallbackCanvasBackend - cairo AzureSkiaAccelerated - 0 more info: all Firefox windows are whole in white ================================================ GPU Accelerated Windows - Direct3D 10 windowLayerManagerRemote - false AzureCanvasBackend - direct2d AzureContentBackend - direct2d 1.1 AzureFallbackCanvasBackend - cairo AzureSkiaAccelerated - 0 layers.offmainthreadcomposition.enabled = false more info: no crash (was crashing some days ago, it only crashes when I change "layers.offmainthreadcomposition.enabled" to "false" and it's bug #1062513 ) ================================================ GPU Accelerated Windows - Direct3D 9 (OMTC) windowLayerManagerRemote - true AzureCanvasBackend - skia AzureContentBackend - cairo AzureFallbackCanvasBackend - cairo AzureSkiaAccelerated -1 layers.prefer-d3d9 = true more info: no crash, minimize/maximize/close buttons aren't visible ================================================ GPU Accelerated Windows - Direct3D 9 layers.offmainthreadcomposition.enabled = false layers.prefer-d3d9 = true https://crash-stats.mozilla.com/report/index/fd9f53e1-eb06-46a1-88a5-a7d312141004 https://crash-stats.mozilla.com/report/index/26a5b123-582b-4f01-a827-327fd2141004 more info: crash on start and looks like it's bug #1036742 ================================================ GPU Accelerated Windows - Basic windowLayerManagerRemote - false AzureCanvasBackend - direct2d AzureContentBackend - direct2d 1.1 AzureFallbackCanvasBackend - cairo AzureSkiaAccelerated - 0 layers.offmainthreadcomposition.enabled = false layers.prefer-opengl = true more info: no crash, minimize/maximize/close buttons flickers on scrolling ================================================ GPU Accelerated Windows - OpenGL (OMTC) windowLayerManagerRemote - true AzureCanvasBackend - direct2d AzureContentBackend - direct2d 1.1 AzureFallbackCanvasBackend - cairo AzureSkiaAccelerated - 0 layers.prefer-opengl = true https://crash-stats.mozilla.com/report/index/811c77fb-756b-486f-bf89-4d2232140929 more info: sometimes crashes, whole browser window are in small artifacts on borders, web content is moved oddly - when you want to select some link etc. you need to move your mouse above or under the link some pixels as it won't work ================================================ GPU Accelerated Windows - Basic (OMTC) windowLayerManagerRemote - true AzureCanvasBackend - skia AzureContentBackend - cairo AzureFallbackCanvasBackend - cairo AzureSkiaAccelerated - 1 gfx.direct2d.disabled = true layers.acceleration.disabled = true more info: no crash, no artifacts ================================================ GPU Accelerated Windows - Basic windowLayerManagerRemote - false AzureCanvasBackend - skia AzureContentBackend - cairo AzureFallbackCanvasBackend - cairo AzureSkiaAccelerated - 1 gfx.direct2d.disabled = true layers.acceleration.disabled = true layers.offmainthreadcomposition.enabled = false more info: no crash, minimize/maximize/close buttons flickers on scrolling

My info from Graphics section in about:support with default settings Adapter Description - NVIDIA GeForce GTX 460 v2 Adapter Drivers - nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM - 1024 Device ID - 0x1205 Direct2D Enabled - true DirectWrite Enabled - true (6.2.9200.16571) Driver Date - 9-13-2014 Driver Version - 9.18.13.4411 GPU #2 Active - false GPU Accelerated Windows - 1/1 Direct3D 11 (OMTC) Subsys ID - 00000000 Vendor ID - 0x10de WebGL Renderer - Google Inc. -- ANGLE (NVIDIA GeForce GTX 460 v2 Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote - true AzureCanvasBackend - direct2d AzureContentBackend - direct2d 1.1 AzureFallbackCanvasBackend - cairo AzureSkiaAccelerated - 0

My next observations based on test with Firefox Portable Firefox Nightly 35.0a1 - affected Firefox Aurora 34.0a2 - affected Firefox Beta 33.0b9 - affected Firefox 32.0.3 - kinda affected or maybe other bug? Firefox 31.0 - not affected

That's how it look like when you do STR and minimize and maximize the Firefox window

On Firefox 32.0.3 when I scroll down and up the page in STR, I will lose visibility of all Firefox buttons...

Tracking for 33 as depending on how this works out it may be a candidate for a ride along.

Toady in duplicate bug #1081491 posted a video about this issue > Link to video > http://www.mediafire.com/watch/w09ixb0wxlyvac2/nvidia_bug.mp4

Did my logs help in any way?

Probably not Nvidia only. I get those issues on my 2500k with the integrated Intel HD 3000, although it happens quite randomly there and is far less reproducible than what you and Toady are seeing. Also my browser display is mainly "freezing", but my firefox button sometimes still works for some time (and even renders correctly), or can be used even if it is all-white to close the browser. Also all-white mostly happens after loosing focus. So I'm not sure if our problems are the same, but that's also probably just differences caused by the drivers. Btw are you using Nvidia Optimus technology? There's someone who wrote a comment in the OpenSharedResource D3D11 doc[1] that this sometimes returns black or white frames when textures are shared between GPUs and doesn't fail correctly as it should. I don't know the underlying code, but looking at the places where we asserted related to drawing we sometimes don't check the return values of those functions or don't add them to the assert. In the D3D9 (OMTC) log for example we fail here: https://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d9/CompositorD3D9.cpp#188 check return code and on error assert with the hresult. (In this case according to the log we're doing an DXGI_ERROR_INVALID_CALL). This is how it should be done imho. As :Virtual only mentions invisible minimize/maximize/close buttons there, let's look at the more important D3D11 (OMTC) case, failing at: https://mxr.mozilla.org/mozilla-central/source/gfx/layers/d3d11/TextureD3D11.cpp#435 Unfortunately we don't include the return code in the assert here, but failing to open a shared texture really doesn't look nice. It'd be nice to know the error code we're getting there. Any way, I will get back to my desktop where I'm seeing those problems in about a week and will try to get logs from a debug build there too. [1] http://msdn.microsoft.com/en-us/library/windows/desktop/ff476531%28v=vs.85%29.aspx

(In reply to Johannes Pfrang [:johnp] from comment #31) > Btw are you using Nvidia Optimus technology? I don't. I have only one GPU (NVIDIA GTX 460 v2) and CPU without integrated GPU (Intel Core 2 Duo E6550)

Can you check whether this commit https://bugzilla.mozilla.org/show_bug.cgi?id=1082660#c10 caused the problem? i.e. try a Nightly immediately before and after that date.

Hi Gian-Carlo Pascutto as per https://bugzilla.mozilla.org/show_bug.cgi?id=1064864#c33 affected: Window hang ftp://ftp.mozilla.org/pub/firefox/nightly/2014/09/2014-09-30-03-02-02-mozilla-central/ BuildID=20140929030205 SourceStamp=9d66436af432 affected: Crash https://crash-stats.mozilla.com/report/index/bp-634e4d53-cf90-46e5-89b0-eb2662141017 ftp://ftp.mozilla.org/pub/firefox/nightly/2014/08/2014-08-31-03-02-06-mozilla-central/ BuildID=20140831030206 SourceStamp=1db35d2c9a2f not affected: not affected ftp://ftp.mozilla.org/pub/firefox/nightly/2014/07/2014-07-31-03-02-06-mozilla-central/ BuildID=20140731030206 SourceStamp=005424a764da I hope this is the data you required.

As highlighted here https://bugzilla.mozilla.org/show_bug.cgi?id=1057716#c18 https://hg.mozilla.org/releases/mozilla-beta/rev/9eb4dff42df0 Changing srcBox.back = 1; back to srcBox.back = 0; Resolves the issue can anyone else confirm.

>I hope this is the data you required. Well, there's a month between the affected and unaffected build you listed, so that doesn't help much in narrowing it down. The links to the Nightlies immediately before and after that date (26th August) are here: https://bugzilla.mozilla.org/show_bug.cgi?id=1067317#c15 As for comment 35, did you test your own build or something? If reverting that change indeed fixes the bug then this bug and bug 1082660 are dupes, which is what I wanted to confirm.

Hi Gian-Carlo Pascutto As per https://bugzilla.mozilla.org/show_bug.cgi?id=1067317#c15 25 August Nightly: no hangs or crashes 27 August Nightly: hangs and crashes https://crash-stats.mozilla.com/report/index/bp-a1664175-4155-4341-858b-415062141018 As for https://bugzilla.mozilla.org/show_bug.cgi?id=1064864#c35 yes, i have tested it in a vs2010, vs2012 & vs2013 compile of Firefox 33 and i am unable to produce the bug after reverting that change, i was hoping someone could confirm it. So they are likely to be duplicate or connected.

Was bisected in bug 1082660: https://bugzilla.mozilla.org/show_bug.cgi?id=1082660#c10

(In reply to Toady from comment #37) > Hi Gian-Carlo Pascutto > > As per https://bugzilla.mozilla.org/show_bug.cgi?id=1067317#c15 > > 25 August Nightly: no hangs or crashes > > 27 August Nightly: hangs and crashes I can confirm it.

@Gian-Carlo Pascutto I think this commit coincides with this bug date 27 August Nightly https://github.com/mozilla/gecko-dev/commit/c7028a4f92055a8284bab7c2ecf7bc636d6b688c Has anyone else been able to confirm backing out this change resolves it?

Bas, can you help here?

Issue still present in ftp://ftp.mozilla.org/pub/firefox/candidates/33.0.1-candidates/build1/ However the window can go completely white and starts to detach inside the window see attached image. Issue not present when https://bugzilla.mozilla.org/show_bug.cgi?id=1064864#c42 backing out the mentioned change.

Can we back out the patch that caused this issue if it won't be fixed soon?

Any chance a patch can be uplifted to 33.1 or has that train already left the station like the previous 33.0.1 - 33.0.2 releases, Does backing out said change reintroduce https://bugzilla.mozilla.org/show_bug.cgi?id=1057716 Still currently affects 33.0 - 36.0

Does the build here: https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-71826c91fb76/ still have the problem?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #48) > Does the build here: > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ > jmuizelaar@mozilla.com-71826c91fb76/ still have the problem? FYI, the build's not there yet: https://tbpl.mozilla.org/?tree=Try&rev=71826c91fb76

(In reply to Jeff Muizelaar [:jrmuizel] from comment #48 and comment #49) Using this build: Firefox Nightly 33.0.1 Build ID - 20141030070712 Built from https://hg.mozilla.org/try/rev/71826c91fb76 I still can reproduce my bug. You can't? Please also look on Toady comments here.

(In reply to Virtual_ManPL [:Virtual] from comment #50) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #48 and comment #49) > > Using this build: > Firefox Nightly 33.0.1 > Build ID - 20141030070712 > Built from https://hg.mozilla.org/try/rev/71826c91fb76 > > I still can reproduce my bug. > You can't? I haven't reproduced the bug at all yet. This was just a theory I had for what could be going wrong.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #48) > Does the build here: > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ > jmuizelaar@mozilla.com-71826c91fb76/ still have the problem? 33.0.2 crashes for me, but that build fixes the bug for me. >============================================================================== Graphics -------- Adapter Description: NVIDIA GeForce GT 640 Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM: 2048 ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200 Device ID: 0x0fc1 Direct2D Enabled: true DirectWrite Enabled: true (6.2.9200.16571) Driver Date: 10-16-2014 Driver Version: 9.18.13.4448 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Vendor ID: 0x10de WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GT 640 Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: true AzureCanvasBackend: direct2d AzureContentBackend: direct2d AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0 Important Modified Preferences ------------------------------ gfx.direct3d.last_used_feature_level_idx: 0 >============================================================================== For comparison, Nighty of 2014-10-30 is crashing. >============================================================================== Graphics -------- Adapter Description: NVIDIA GeForce GT 640 Adapter Drivers: nvd3dumx,nvwgf2umx,nvwgf2umx nvd3dum,nvwgf2um,nvwgf2um Adapter RAM: 2048 ClearType Parameters: Gamma: 2200 Pixel Structure: R ClearType Level: 100 Enhanced Contrast: 200 Device ID: 0x0fc1 Direct2D Enabled: true DirectWrite Enabled: true (6.2.9200.16571) Driver Date: 10-16-2014 Driver Version: 9.18.13.4448 GPU #2 Active: false GPU Accelerated Windows: 1/1 Direct3D 11 (OMTC) Subsys ID: 125819da Vendor ID: 0x10de WebGL Renderer: Google Inc. -- ANGLE (NVIDIA GeForce GT 640 Direct3D9Ex vs_3_0 ps_3_0) windowLayerManagerRemote: true AzureCanvasBackend: direct2d AzureContentBackend: direct2d 1.1 AzureFallbackCanvasBackend: cairo AzureSkiaAccelerated: 0 Important Modified Preferences ------------------------------ gfx.direct3d.last_used_feature_level_idx: 0 >============================================================================== https://crash-stats.mozilla.com/report/index/f48006a3-c257-4fc4-9911-770a42141030

(In reply to Elbart from comment #52) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #48) > > Does the build here: > > https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/ > > jmuizelaar@mozilla.com-71826c91fb76/ still have the problem? > > 33.0.2 crashes for me, but that build fixes the bug for me. Can anyone else confirm that this build works? When does the crash you get on Nightly happen? On startup?

(In reply to Jeff Muizelaar [:jrmuizel] from comment #53) > Can anyone else confirm that this build works? Sorry, spoke too soon. I was testing by hitting "End" before the page finished loading to go down to the bars, and this way the browser doesn't break immediately. Waiting until the loading is done, scrolling down freezes the UI, and also with that try-build. > When does the crash you get on Nightly happen? On startup? That crash-report happened when I scrolled down to the bars.

(In reply to Elbart from comment #54) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #53) > > Can anyone else confirm that this build works? > > Sorry, spoke too soon. > > I was testing by hitting "End" before the page finished loading to go down > to the bars, and this way the browser doesn't break immediately. > Waiting until the loading is done, scrolling down freezes the UI, and also > with that try-build. > > > When does the crash you get on Nightly happen? On startup? > > That crash-report happened when I scrolled down to the bars. Ok, that's good news. I expect we're detecting the problem in Nightly and crashing instead doing random bad stuff like we do now.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #55) > (In reply to Elbart from comment #54) > > (In reply to Jeff Muizelaar [:jrmuizel] from comment #53) > > > Can anyone else confirm that this build works? > > > > Sorry, spoke too soon. > > > > I was testing by hitting "End" before the page finished loading to go down > > to the bars, and this way the browser doesn't break immediately. > > Waiting until the loading is done, scrolling down freezes the UI, and also > > with that try-build. > > > > > When does the crash you get on Nightly happen? On startup? > > > > That crash-report happened when I scrolled down to the bars. > > Ok, that's good news. I expect we're detecting the problem in Nightly and > crashing instead doing random bad stuff like we do now. Can other people confirm that trunk crashes in same situations where 33 hangs?

Elbart, can you try this build: http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla-inbound-win32/1414608732/. I expect it to crash. Can you post a crash report from it?

Using this build: Firefox Nightly 36.0a1 (2014-10-29) Build ID - 20141029115212 Built from https://hg.mozilla.org/integration/mozilla-inbound/rev/c30b79646349 and no crash here with Direct3D 11 (OMTC), only whole content is frozen and when you minimize and next maximize the Firefox window, all Firefox windows are in white like on attached screenshots (windows buttons still works, so you can close/maximize/minimize the windows) more information about different configurations are in Comment #21

Hi Jeff Muizelaar The issue is still present in the try build, Please try backing out the change set highlighted in this comment https://bugzilla.mozilla.org/show_bug.cgi?id=1064864#c35 then retest. Changing srcBox.back = 1; back to srcBox.back = 0; Resolves the issue but needs to be confirmed. Backing out that small change does not appear to reintroduce https://bugzilla.mozilla.org/show_bug.cgi?id=1057716 but it would be worth checking.

Found a better url for an example: https://www.mozilla.org/en-US/firefox/desktop/customize/ When reproducing the bug on this page by scrolling up and down the page until the animations are finished, Hangs all open windows, Private and console as where https://www.mozilla.org/en-US/firefox/desktop/ just hangs the window it was opened in.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #57) > Elbart, can you try this build: > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla- > inbound-win32/1414608732/. > > I expect it to crash. Can you post a crash report from it? Doesn't crash, just the usual turning white.

(In reply to Elbart from comment #61) > (In reply to Jeff Muizelaar [:jrmuizel] from comment #57) > > Elbart, can you try this build: > > http://ftp.mozilla.org/pub/mozilla.org/firefox/tinderbox-builds/mozilla- > > inbound-win32/1414608732/. > > > > I expect it to crash. Can you post a crash report from it? > > Doesn't crash, just the usual turning white. So Nightly crashes but that build did not? That's pretty weird...

I'm making a new build that I'd like people to try out: https://tbpl.mozilla.org/?tree=Try&rev=bdbda5770000 https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/jmuizelaar@mozilla.com-bdbda5770000/ It's a bit of a shot in the dark, but who knows...

Also try https://ftp.mozilla.org/pub/mozilla.org/firefox/try-builds/bschouten@mozilla.com-555a02e07e0b/ . It's only very subtly different from Jeff's, however it would be interesting to know if one fixes it but not the other.

Yes the issue is no longer present in https://bugzilla.mozilla.org/show_bug.cgi?id=1064864#c63 try build Also no longer present in https://bugzilla.mozilla.org/show_bug.cgi?id=1064864#c64 try build.

Yep, both try-builds are working for me, too (Nvidia GT640). As a sidenote: A machine of mine with IntelHD (first gen) isn't affected by this bug.

(In reply to Jeff Muizelaar [:jrmuizel] from comment #62) > So Nightly crashes but that build did not? That's pretty weird... Nightly never ever crashed with this issue. With both builds this issue is not present and not reproducible anymore. Firefox Nightly 36.0a1 (2014-10-31) Build ID - 20141031133101 Built from https://hg.mozilla.org/try/rev/bdbda5770000 Firefox Nightly 36.0a1 (2014-10-31) Build ID - 20141031141643 Built from https://hg.mozilla.org/try/rev/555a02e07e0b

I've pushed this fix to inbound: https://hg.mozilla.org/integration/mozilla-inbound/rev/6f87e2b18331

Approval Request Comment [Feature/regressing bug #]: OMTC/d3d11 [User impact if declined]: Window with few tabs is locked, frozen and all white in some odd cases [Describe test coverage new/current, TBPL]: This code should be tested through our existing tests. [Risks and why]: This should be pretty low risk. We don't understand the circumstances when this condition is false, but if it ever is we definitely don't want to proceed with copy because it's wrong and appears to make drivers sad.

Have to agree with mcMerge, which was confused about how to assign this bug. https://hg.mozilla.org/mozilla-central/rev/6f87e2b18331

Comment on attachment 8515500 [details] [diff] [review] check.patch Please land also that in m-r GECKO331_2014103013_RELBRANCH (just in case). Thanks

https://hg.mozilla.org/releases/mozilla-aurora/rev/8ede96fbce88 https://hg.mozilla.org/releases/mozilla-beta/rev/d4ad7d727dd6 https://hg.mozilla.org/releases/mozilla-release/rev/1a4c4d3fddf5 (on GECKO331_2014103013_RELBRANCH) (marked 'fixed' on 33 since it landed on a 33 branch)

Thanks jesup! Sorry but it has to land on m-r master too (ie not only on the GECKO331_2014103013_RELBRANCH)

Thank you guys! It's fixed.

Yes, Thank you kindly as well :) its fixed hardware acceleration can be turned back on now.

This did not make 33.0.3, right?

Yes... ;/ as I can still reproduce it with Firefox 33.0.3 Build ID - 20141105223254 Built from https://hg.mozilla.org/releases/mozilla-release/rev/983a710b51c4 kinda funny as it even locks on - https://www.mozilla.org/en-US/firefox/desktop/?utm_source=Thundrclap&utm_medium=Thunderclap&utm_campaign=FX10

Am I reading this wrong, or is the rev of comment 74 only tagged for a 33.1(?) release?

(In reply to Elbart from comment #79) > Am I reading this wrong, or is the rev of comment 74 only tagged for a > 33.1(?) release? It seems :( Could you try with http://ftp.mozilla.org/pub/mozilla.org/firefox/nightly/33.1-candidates/ ?

Looks fixed with: Firefox 33.1 (RC3) Build ID - 20141106120505 Built from https://hg.mozilla.org/releases/mozilla-release/rev/a4d51da32fe7 but still it's very odd that it doesn't make to Firefox 33.0.3...

(In reply to Virtual_ManPL [:Virtual] from comment #81) > but still it's very odd that it doesn't make to Firefox 33.0.3... For 33.0.3, we used a specific relbranch. Unfortunately, I confused the 33.0.* and the 33.1 relbranch...

No it din'tt land in 33.0.3 or 33.1 (Birthday edition) But is patched in 33.1.1 candidate build1

(In reply to Toady from comment #83) > No it din'tt land in 33.0.3 or 33.1 (Birthday edition) > But is patched in 33.1.1 candidate build1 What make you say that? It did land in 33.1.

(In reply to Sylvestre Ledru [:sylvestre] from comment #84) > (In reply to Toady from comment #83) > > No it din'tt land in 33.0.3 or 33.1 (Birthday edition) > > But is patched in 33.1.1 candidate build1 > What make you say that? It did land in 33.1. Sorry was looking in 33.1 candidate build2 archive, Yes it was patched in build 3 the release build.