626678 - Firefox becomes unresponsive when docking or undocking my laptop

Status: RESOLVED FIXED

(Core :: Graphics, defect)

Description

[brian.cyrai]

User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0b9) Gecko/20100101 Firefox/4.0b9
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0b9) Gecko/20100101 Firefox/4.0b9

I'm using a Lenovo T61p and the official Lenovo dock for it. Whenever I dock or undock my laptop, Firefox becomes completely unresponsive. If Firefox is minimized and I maximize it, the only thing that appears is the title bar of the application. Where there would otherwise be the toolbars and my tabs, all I see is whatever was on screen before I maximized Firefox. As far as I can tell, the only way to resolve this problem once it's happened is to close Firefox and reopen it. This change was introduced in beta 8; beta 7 didn't have this problem

Reproducible: Always

Steps to Reproduce:
1.Have my laptop or probably one similar to it
2.Dock or undock the laptop from the laptop dock
3.
Actual Results:  
Firefox becomes unresponsive until I close it and reopen

Expected Results:  
I expect to be able to look at my tabs and use Firefox like I could before I docked or undocked my laptop

Comment 1

[Matthias Versen [:Matti]]

I guess you mean with "Unresponsive" that only the content of the window is invisible.
This looks like bug 621516 but that reporter got the problem already with b7
Please post the graphic section from about:support

Comment 2

[brian.cyrai]

Yeah, that looks similar to that bug. I tried to search for something to make sure I wasn't opening a duplicate, but I was only searching for docking. What do you mean by the graphic section from about:support? The Help->About Firefox doesn't have anything about support.

Comment 3

[Bas Schouten (:bas.schouten)]

Could you try with the latest nightly? We've made some changes here that will hopefully have fixed this situation!

Comment 4

[brian.cyrai]

How do I get the latest nightly?

Comment 5

[Matthias Versen [:Matti]]

type about:support in the Firefox URL bar (address bar, the place where you type URLs).

You can download the nightly builds from ftp://ftp.mozilla.org/pub/firefox/nightly/latest-mozilla-central/

Comment 6

[brian.cyrai]

Nope. No go. I'm assuming the build is supposed to be called Minefield? Here's about:support

Adapter Description: NVIDIA Quadro FX 570M
Vendor ID: 10de
Device ID: 040c
Adapter RAM: Unknown
Adapter Driver: snv4_disp
Driver Version: 6.14.11.9716
Driver Date: 3-16-2010
Direct2D Enabled: false
DirectWrite Enabled: false
WebGL Renderer: TransGaming Inc. -- ANGLE -- OpenGL ES 2.0 (git-devel Jan 10 2011 19:54:16)
GPU Accelerated Windows: 1/1 Direct3D 9

Comment 7

[Matthias Versen [:Matti]]

>I'm assuming the build is supposed to be called Minefield?
Yes because it's a build that is only tested with automated tests and it's automatically generated over the night with the latest source code changes. The name should only make sure that you as user recognize that.

A workaround for you would be to disable the hardware acceleration under (alt key)/tools/options/advanced/general

Comment 8

[brian.cyrai]

Disabling hardware acceleration worked. Thanks, because that was starting to seriously get old

Comment 9

[Paul Webb]

I have a Dell M4400 with the exact same problem.  Still present in 4b10

Adapter DescriptionNVIDIA Quadro FX 770M
Vendor ID10de
Device ID065c
Adapter RAM Unknown
Adapter Drivers nv4_dispDriver Version6.14.12.5896
Driver Date7-9-2010
Direct2D Enabled false
DirectWrite Enabled false (0.0.0.0)
WebGL Renderer NVIDIA Corporation -- Quadro FX 770M/PCI/SSE2 -- 3.3.0GPU Accelerated Windows2/2 Direct3D 9

Comment 10

[Matthias Versen [:Matti]]

Disabling the hardware acceleration helps in your case ?

Comment 11

[brian.cyrai]

I guess I should also mention that I still saw this problem in b10 until I disabled hardware acceleration again

Comment 12

[Paul Webb]

Yes it did, disabling hardware acceleration solved the problem; is this an NVIDIA related bug?

As an aside, I run 2 displays (my laptop + another screen attached to the docking station) when I'm plugged in.  Could be related.

Comment 13

[brian.cyrai]

Come to think of it, so do I. That might be the more likely culprit, because there's probably fewer people with docks and two monitors than just docks, and this doesn't seem to be a commonly reported defect

Comment 14

[Jean-François Bastien]

I get the same problem when docking/undocking a Dell Latitude E6400 on the Dell docking station, plugged in to two monitors. I've been having this problem for quite a while, I run the betas on WinXP.

If you want to test this out I can swing by the Mozilla office with the laptop and docking station (my housemate works in the JS team, I live a mile from Castro).


  Graphics

        Adapter Description
        NVIDIA Quadro NVS 160M

        Vendor ID
        10de

        Device ID
        06eb

        Adapter RAM
        Unknown

        Adapter Drivers
        nv4_disp

        Driver Version
        6.14.11.7626

        Driver Date
        8-1-2008

        Direct2D Enabled
        false

        DirectWrite Enabled
        false (0.0.0.0)

        WebGL Renderer
        NVIDIA Corporation -- Quadro NVS 160M/PCI/SSE2 -- 2.1.2

        GPU Accelerated Windows
        1/1 Direct3D 9

Comment 15

[Jeff Muizelaar [:jrmuizel]]

Vlad, do you think you can connect with Jean-François to try to figure out what's happening?

Comment 16

[David Dahl :ddahl]

Vlad: I have similar hardware (alienware) if you need any kind of help at all.

Comment 17

[Jeff Muizelaar [:jrmuizel]]

It would be interesting to attach a debugger to firefox after it's gone unresponsive to see what it's doing. i.e. is it responding to paint events that just aren't getting to the screen?

Comment 18

[Jeff Muizelaar [:jrmuizel]]

In reply to comment #16)
> Vlad: I have similar hardware (alienware) if you need any kind of help at all.

David, can you attach a debugger?

Comment 19

[Joe Drew (not getting mail)]

Benoit has such a computer!

Comment 20

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #19)
> Benoit has such a computer!

Apparently he does not.

Comment 21

[Jeff Muizelaar [:jrmuizel]]

Benoit was not able to reproduce it with his thinkpad.

Comment 22

[Jean-François Bastien]

I'm also unable to repro the problem, it used to occur every single time I docked/undocked but now it never happens. If it does occur again I'll attach a debugger, but for now I can't repro.

Comment 23

[Joe Drew (not getting mail)]

Can anyone reproduce this now?

Comment 24

[David Dahl :ddahl]

I will try this evening as well - I just got off of a plane and am in a meeting all day.

Comment 25

[Paul Webb]

I can still reproduce the problem after re-enabling hardware acceleration with b11 and the latest NVIDIA driver (266.45) installed on my system.

Adapter Description  NVIDIA Quadro FX 770M
Vendor ID  10de
Device ID  065c
Adapter RAM  Unknown
Adapter Drivers  nv4_dispDriver Version6.14.12.6645
Driver Date  12-27-2010
Direct2D Enabled  false
DirectWrite Enabled  false (0.0.0.0, font cache n/a)
WebGL Renderer  NVIDIA Corporation -- Quadro FX 770M/PCI/SSE2 -- 3.3.0
GPU Accelerated Windows  1/1 Direct3D 9

Comment 26

[(mostly gone) XtC4UaLL [:xtc4uall]]

FWIW, on Bug 633904 somebody reported this Issue against a Intel Card with D3D9 (what seems to be a common Factor) with WinXP/Fx4 b11.

Comment 27

[David Dahl :ddahl]

BTW: I can help run tests and do some gdb stack capturing, but this bug is way out of my area of expertise. Re-assigning to default.

Comment 28

[Jeff Muizelaar [:jrmuizel]]

Can anyone reproduce this problem on a version of Windows newer than XP?

Comment 29

[Jeff Muizelaar [:jrmuizel]]

Also, do other D3D9 programs continue to work after docking/undocking?

Comment 30

[Joe Drew (not getting mail)]

I wonder if this is a D3D9-only bug, actually! I bet Benoit didn't test that, because the default configuration is D3D10.

Comment 31

[brian.cyrai]

I don't know what a D3D9 program is, but Firefox is the only application I ever saw trouble with

Comment 32

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #30)
> I wonder if this is a D3D9-only bug, actually! I bet Benoit didn't test that,
> because the default configuration is D3D10.

We tested D3D9 on Benoit's laptop, no difference. We could try without D3D9Ex though.

Comment 33

[Joe Drew (not getting mail)]

Or we could install XP on his laptop!

Comment 34

[(no longer active)]

(In reply to comment #33)
> Or we could install XP on his laptop!

Is this hardware specific?  We might have a machine to experiment with at the office...

Comment 35

[Joe Drew (not getting mail)]

Paul, can you try out a nightly and see if it still happens? http://nightly.mozilla.org

We've had a lot of trouble reproducing this internally. :(

Jean-François, are you running nightlies or betas? Did this stop happening at any particular time?

Comment 36

[Joe Drew (not getting mail)]

We don't think this blocks any more, because it only happens with docking stations and even then only sometimes.

Comment 37

[brian.cyrai]

By sometimes, you mean only to some people, correct? Because when it does happen to someone, it happens every time

Comment 38

[Jean-François Bastien]

On this machine I use the betas, not the nightlies. It stopped happening some time last week, but as this is my work machine I'm not quite sure when (and I'm not quite sure about when I updated the beta either).

It was happening to me reliably before that date, though.

Comment 39

[Joe Drew (not getting mail)]

If you go into about:support, do you still have Direct3D 9 hardware accelerated windows? It's possible that your driver is just old enough that updating to beta 11 blocked it.

Comment 40

[Jean-François Bastien]

I now have the following. Let me know if there's anything you want me to try out, or if you want me to come by the Mozilla office with the laptop and docking station.

It's quite funny that I have an outdated NV driver, being that the machine belongs to NV :-)

        Adapter Description
        NVIDIA Quadro NVS 160M

        Vendor ID
        10de

        Device ID
        06eb

        Adapter RAM
        Unknown

        Adapter Drivers
        nv4_disp

        Driver Version
        6.14.11.7626

        Driver Date
        8-1-2008

        Direct2D Enabled
        Blocked on your graphics driver. Try updating your graphics driver to version 257.21 or newer.

        DirectWrite Enabled
        false (0.0.0.0, font cache n/a)

        WebGL Renderer
        (WebGL unavailable)

        GPU Accelerated Windows
        0/1

Comment 41

[Joe Drew (not getting mail)]

OK then! Updating your NVIDIA driver will likely restore this bug, so it hasn't gone away - we know that Paul still sees it, for example.

Comment 42

[Paul Webb]

I just downloaded the latest minefield build, no change.

To recap:

Happens on nVidia Quadro, latest build.
Windows XP/32.
Laptop is moved to/from a docking station with an external monitor attached.  When docked, the laptop is using both its native screen, and the external display as well as an extended desktop.

I understand the need to get Firefox 4 out the door, and I've been thrilled with what I've seen thus far, but to echo Brian's comment: this bug is extremely annoying to those who experience it; it will make others strongly consider using a different browser.

Comment 43

[Jean-François Bastien]

Ok, so I think this bug should go back to blocker.

Upgrading to the latest NV driver re-enables GPU acceleration, and on reboot Firefox started and (without even dock/undock) it had a dead UI. I could CTRL+TAB and the title bar changed, and I could CTRL+T to open a new tab, typing showed the autocomplete that appears under the navigation bar, but the rest of the UI was dead (displayed whatever happened to have been drawn at that location before).

I captured a minidump of this, but going through the threads (without symbols) didn't show me anything interesting. Let me know if you want the minidump.

I re-iterate my offer to come by the Mozilla office to let you guys try this out.

Comment 44

[Jeff Muizelaar [:jrmuizel]]

I've been able to reproduce this issue.

Comment 45

[Jeff Muizelaar [:jrmuizel]]

It looks like this is what is happening:

VerifyReadyForRendering() is called
 - SUCCEEDED(mDevice->TestCooperativeLevel()) is false
 - We go on down and release our resources
 - hr = mDevice->Reset(&pp); is called 
 - hr is D3DERR_DEVICELOST
 - VerifyReadyForRendering returns false
 - SwapChainD3D9::PrepareForRendering() returns false
 - LayerManagerD3D9::Render() returns

This process seems to repeat for every paint event. It's not clear to me how
we're supposed to exit this situation.

Comment 46

[Jeff Muizelaar [:jrmuizel]]

Removing

562   if (hr == D3DERR_DEVICELOST) {
563     return false;
564   }

fixes the problem.

Comment 47

[Bas Schouten (:bas.schouten)]

The device is -supposed- to return NOTRESET when it's ready to be reset.

The state will be DEVICELOST during a screen lock for example.

Comment 48

[Jeff Muizelaar [:jrmuizel]]

There's also something weird that is probably related. After docking, we are no longer able to start Minefield with accelerated layers until rebooting. Perhaps connecting the docking station makes it so that we can't create the device that we want...

Comment 49

[Mike Beltzner [:beltzner, not reading bugmail]]

Is the issue here using the extended display (ie: universal across all docking stations)? Is it limited to the NVIDIA drivers?

Even in cases where it's "PCs with docking stations who then extend their display across a second monitor" and the effect is "completely unresponsive" then I think this needs to hard block.

Comment 50

[Joe Drew (not getting mail)]

It is not limited to NVIDIA drivers - we can reproduce this on Shaver's old ATI laptop.

We're certainly treating this as a hard blocker in the office, so I'm going to mark it as such. Bas and Jeff are currently working on a solution.

Comment 51

[Bas Schouten (:bas.schouten)]

My idea here is that our D3DADAPTER_DEFAULT is going lost, and we're getting other adapters instead, but we don't use those. What we probably want to do is use MonitorForWindow to figure out which monitor we're running on, and if that monitor no longer matches our adapter -and- the adapter is returning DEVICELOST, we should toss out the layer manager and attempt to recreate.

The creation code should also be updated to use the adapter specified by MonitorForWindow.

Comment 52

[Jean-François Bastien]

I don't know how expensive layer manager recreation is, and what its side-effects are, but here's a dirty hack that might make this issue less of a blocker: on minimize/restore recreate the layer manager.

If it has no bad side effects on what the window looks like and isn't expensive then it's kind of a fail safe in case some bugs ship with 4.0. Instead of having to restart FF the user just has to minimize/restore. It's nowhere near being a good solution, but it seems like a good compromise between getting everything right and **** off users because they have to restart FF.

It effectively hides bugs that might still be around, and if you log the state of things when you recreate then you can probably still detect and fix these bugs (assuming you have a way to get these logs, and that reading them tells you something was wrong).

Comment 53

[Jeff Muizelaar [:jrmuizel]]

(In reply to comment #47)
> The state will be DEVICELOST during a screen lock for example.

This doesn't seem to be the case. I've been unable to get Reset() to produce a DEVICE_LOST unless I go through the docking station dance. We seem to not call VerifyReadyForReady during screen lock. I wonder if it would be safe to just try to recreate the device if Reset() returns DEVICE_LOST?

Comment 54

[Bas Schouten (:bas.schouten)]

(In reply to comment #53)
> (In reply to comment #47)
> > The state will be DEVICELOST during a screen lock for example.
> 
> This doesn't seem to be the case. I've been unable to get Reset() to produce a
> DEVICE_LOST unless I go through the docking station dance. We seem to not call
> VerifyReadyForReady during screen lock. I wonder if it would be safe to just
> try to recreate the device if Reset() returns DEVICE_LOST?

Safe, yes, not the best approach perf wise. There's lots of situations where device lost is returned but maybe our event handling already makes sure we never try to render in those situations so never try to reset them.

Comment 55

[Jeff Muizelaar [:jrmuizel]]

Attachment: A debugging patch that fixes the problem.

Bas, this patch fixes the problem. There's a bunch of extra debugging code, but what do you think of the approach?

I don't know anyway to trigger the *p = 5 crash. Advice?

Comment 56

[Bas Schouten (:bas.schouten)]

Comment on attachment 514227 [details] [diff] [review]
A debugging patch that fixes the problem.

Careful with the tabs in case you didn't notice they were in there :).

I think the general approach is good.

From MSDN: 'By design, the full set of scenarios that can cause a device to become lost is not specified. Some typical examples include loss of focus, such as when the user presses ALT+TAB or when a system dialog is initialized. Devices can also be lost due to a power management event, or when another application assumes full-screen operation. In addition, any failure from IDirect3DDevice9::Reset puts the device into a lost state.'

So, additional things to try are locking the screen, while an HTML5 video is playing. Or a Flash ad is animating or something like that. But in those cases we might not trigger WM_PAINT events and thus not run any transactions. So on the next draw we might just get a DEVICENOTRESET because it only occurs once we have focus again.

Another thing you could try is running some kind of D3D9 full screen application. (Some sample in the DXSDK will do no doubt)

Comment 57

[Jeff Muizelaar [:jrmuizel]]

Attachment: Actual version

Comment 58

[Bas Schouten (:bas.schouten)]

Comment on attachment 514286 [details] [diff] [review]
Actual version

If this fixes the bug I can live with the slight possibility of it being overly aggressive in rare scenarios!

>diff --git a/gfx/cairo/cairo/src/cairo-win32-font.c b/gfx/cairo/cairo/src/cairo-win32-font.c
>--- a/gfx/cairo/cairo/src/cairo-win32-font.c
>+++ b/gfx/cairo/cairo/src/cairo-win32-font.c
>@@ -377,9 +377,16 @@ _win32_scaled_font_set_world_transform (
> 
>     _cairo_matrix_to_win32_xform (&scaled_font->logical_to_device, &xform);
> 
>-    if (!SetWorldTransform (hdc, &xform))
>+    if (!SetWorldTransform (hdc, &xform)) {
>+	printf("%f %f %f %f, %f %f\n",
>+			xform.eM11,
>+			xform.eM12,
>+			xform.eM21,
>+			xform.eM22,
>+			xform.eDx,
>+			xform.eDy);
> 	return _cairo_win32_print_gdi_error ("_win32_scaled_font_set_world_transform");
>-
>+	}
>     return CAIRO_STATUS_SUCCESS;
> }
> 

This hunk doesn't belong here I think :).

>diff --git a/gfx/layers/d3d9/DeviceManagerD3D9.cpp b/gfx/layers/d3d9/DeviceManagerD3D9.cpp
>--- a/gfx/layers/d3d9/DeviceManagerD3D9.cpp
>+++ b/gfx/layers/d3d9/DeviceManagerD3D9.cpp
>@@ -332,6 +332,14 @@ DeviceManagerD3D9::Init()
>     return false;
>   }
> 
>+  D3DDEVICE_CREATION_PARAMETERS parameters;
>+
>+  if (FAILED(mDevice->GetCreationParameters(&parameters)))
>+    return false;
>+
>+  mDeviceMonitor = mD3D9->GetAdapterMonitor(parameters.AdapterOrdinal);
>+
>+

Nit: I think we should avoid the needless line of whitespace here.

>   /* 
>    * Do some post device creation setup 
>    */ 
>@@ -560,7 +568,22 @@ DeviceManagerD3D9::VerifyReadyForRenderi
>   ++mDeviceResetCount;
> 
>   if (hr == D3DERR_DEVICELOST) {
>-    return false;
>+    /* it is not unusual for Reset to return DEVICELOST
>+       we're supposed to continue trying until we get
>+       DEVICENOTRESET and then Reset is supposed to succeed.
>+       Unfortunately, it seems like when we dock or undock
>+       DEVICELOST happens and we never get DEVICENOTRESET. */

I'd personally prefer a * on every line like with the other comments.

Comment 59

[Jeff Muizelaar [:jrmuizel]]

Attachment: final version

A version with some more comments and review adjustments made.

Comment 60

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

http://hg.mozilla.org/mozilla-central/rev/8dd9704f8d81

Comment 61

[Paul Webb]

I just tested my machine with last night's build; looks great.  Thanks for everyone's attention (especially Bas and Jeff) and work on this!

Comment 62

[Jean-François Bastien]

Is it supposed to be fixed in beta 12? I'm still seeing this problem.

Comment 63

[Mounir Lamouri (:mounir)]

(In reply to comment #62)
> Is it supposed to be fixed in beta 12? I'm still seeing this problem.

No. It should be fixed in nightlies and it will be fixed in the first RC.

Comment 64

[Mike Shaver (:shaver -- probably not reading bugmail closely)]

I don't think it made beta 12.  You could try a nightly (http://nightly.mozilla.org) and verify the fix there.

Comment 65

[Jean-François Bastien]

I do use the nightlies at home, but I'd rather not use it on my work laptop. I'll wait for the RC.

Comment 68

[Huygens]

Sorry, I had created Bug 639765 because I looked for external display problem.

It seems I have the same symptoms as you, but I only need to plug-in or out an external display, no need to dock (I don't own one). And it's related to hardware acceleration as once disabled, the bug is not reproducible.

I don't have a NVidia card, just an Intel GMA X4500HD/GM45 (Mobile version) with WinXP driver version 6.14.10.5294.

Comment 69

[Jag]

I am seeing this issue on my Toshiba Tecra Z40-B laptop. Graphics device: Intel HD Graphics 5500