George Wright (:gw280) (needinfo me!) Reporter
	Description • 9 years ago

Fallout from bug 1128062 - if we lose our D3D11 device and compositor, we end up losing the page and never recovering.

Bas assures me that this should never happen under normal circumstances, but we should probably fix the fallback anyway.

	George Wright (:gw280) (needinfo me!) Reporter
	Comment 1 • 9 years ago

This seems to only affect Windows 7 machines that have received the Platform Update. Vanilla Win7 doesn't exhibit this issue.

	Nicolas Silva [:nical]
	Comment 2 • 9 years ago

(In reply to George Wright (:gw280) from comment #0)
> Fallout from bug 1128062 - if we lose our D3D11 device and compositor, we
> end up losing the page and never recovering.
> 
> Bas assures me that this should never happen under normal circumstances, but
> we should probably fix the fallback anyway.

We should be falling back to D3D11 warp in this case, at the moment. We loose the page because we keep trying to create a regular D3D11 compositor or is the warp backend failing too?

	George Wright (:gw280) (needinfo me!) Reporter
	Comment 3 • 9 years ago

WARP was failing. I think we need to account for the potential loss of a WARP device.

	Nicolas Silva [:nical]
	Comment 4 • 9 years ago

Gah. It's like failing at failing.

	Matt Woodrow (:mattwoodrow)
	Comment 5 • 9 years ago

I suspect the main problem here is that we don't call UpdateRenderMode in the child process, which is what detects driver resets and recreates the devices.

In the parent process this happens in nsWindow::OnPaint.

	Milan Sreckovic [:milan] (needinfo for best results)
	Comment 6 • 8 years ago

We should be handling this scenario a lot better now, right David?

	David Anderson [:dvander] - inactive, e-mail if emergency
	Comment 7 • 8 years ago

Yeah, this should be basically solved by now.