Closed Bug 626678 Opened 9 years ago Closed 9 years ago

Firefox becomes unresponsive when docking or undocking my laptop

Categories

(Core :: Graphics, defect)

x86
Windows XP
defect
Not set

Tracking

()

RESOLVED FIXED
mozilla2.0
Tracking Status
blocking2.0 --- final+

People

(Reporter: brian.cyrai, Assigned: jrmuizel)

References

Details

(Whiteboard: [hardblocker][has patch])

Attachments

(1 file, 2 obsolete files)

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
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
Component: General → Graphics
Product: Firefox → Core
QA Contact: general → thebes
Version: unspecified → Trunk
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.
Could you try with the latest nightly? We've made some changes here that will hopefully have fixed this situation!
How do I get the latest nightly?
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/
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
>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
Disabling hardware acceleration worked. Thanks, because that was starting to seriously get old
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
Disabling the hardware acceleration helps in your case ?
I guess I should also mention that I still saw this problem in b10 until I disabled hardware acceleration again
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.
Status: UNCONFIRMED → NEW
Ever confirmed: true
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
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
blocking2.0: --- → betaN+
Whiteboard: [hardblocker]
Assignee: nobody → jmuizelaar
Vlad, do you think you can connect with Jean-François to try to figure out what's happening?
Assignee: jmuizelaar → vladimir
Vlad: I have similar hardware (alienware) if you need any kind of help at all.
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?
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?
Benoit has such a computer!
Assignee: vladimir → bjacob
(In reply to comment #19)
> Benoit has such a computer!

Apparently he does not.
Assignee: bjacob → ddahl
Benoit was not able to reproduce it with his thinkpad.
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.
Can anyone reproduce this now?
I will try this evening as well - I just got off of a plane and am in a meeting all day.
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
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.
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.
Assignee: ddahl → nobody
Can anyone reproduce this problem on a version of Windows newer than XP?
Also, do other D3D9 programs continue to work after docking/undocking?
I wonder if this is a D3D9-only bug, actually! I bet Benoit didn't test that, because the default configuration is D3D10.
Assignee: nobody → bjacob
I don't know what a D3D9 program is, but Firefox is the only application I ever saw trouble with
(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.
Or we could install XP on his laptop!
(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...
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?
We don't think this blocks any more, because it only happens with docking stations and even then only sometimes.
blocking2.0: betaN+ → -
Whiteboard: [hardblocker]
By sometimes, you mean only to some people, correct? Because when it does happen to someone, it happens every time
blocking2.0: - → ---
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.
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.
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
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.
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.
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.
I've been able to reproduce this issue.
Assignee: bjacob → jmuizelaar
blocking2.0: - → ?
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.
Removing

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

fixes the problem.
Assignee: jmuizelaar → 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.
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...
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.
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.
blocking2.0: ? → final+
Whiteboard: [hardblocker]
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.
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).
(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?
(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.
Assignee: bas.schouten → jmuizelaar
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?
Attachment #514227 - Flags: feedback?
Attachment #514227 - Flags: feedback? → feedback?(bas.schouten)
Attachment #514227 - Attachment is patch: true
Attachment #514227 - Attachment mime type: application/octet-stream → text/plain
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)
Attachment #514227 - Flags: feedback?(bas.schouten) → feedback+
Attached patch Actual version (obsolete) — Splinter Review
Attachment #514227 - Attachment is obsolete: true
Attachment #514286 - Flags: review?(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.
Attachment #514286 - Flags: review?(bas.schouten) → review+
Whiteboard: [hardblocker] → [hardblocker][needs landing][has patch]
Attached patch final versionSplinter Review
A version with some more comments and review adjustments made.
Attachment #514286 - Attachment is obsolete: true
Attachment #514512 - Flags: review+
Attachment #514512 - Attachment description: final versoin → final version
http://hg.mozilla.org/mozilla-central/rev/8dd9704f8d81
Status: NEW → RESOLVED
Closed: 9 years ago
Resolution: --- → FIXED
Whiteboard: [hardblocker][needs landing][has patch] → [hardblocker][has patch]
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!
Is it supposed to be fixed in beta 12? I'm still seeing this problem.
(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.
Target Milestone: --- → mozilla2.0
I don't think it made beta 12.  You could try a nightly (http://nightly.mozilla.org) and verify the fix there.
I do use the nightlies at home, but I'd rather not use it on my work laptop. I'll wait for the RC.
Duplicate of this bug: 639765
Duplicate of this bug: 627154
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.
I am seeing this issue on my Toshiba Tecra Z40-B laptop. Graphics device: Intel HD Graphics 5500
You need to log in before you can comment on or make changes to this bug.