Closed Bug 1128062 Opened 9 years ago Closed 9 years ago

Web content blank in e10s mode running in Windows 7 in VMWare

Categories

(Core :: Graphics, defect)

Product:
Core
Component:
Graphics
Platform:
x86
Windows 7
Type:
defect
Priority:
Not set
Severity:
normal

Tracking

()

Status:
RESOLVED DUPLICATE of bug 1147728
Tracking Flags:
Tracking Status
e10s m6+ ---

People

(Reporter: smichaud, Assigned: gw280)

References

Details

(Keywords: regression, Whiteboard: [gfx-noted][work around in comment 23])

Attachments

(1 file)

about support information from Nightly build 1.12.2015
(deleted), text/plain
Details 
For me at least, this happens in today's mozilla-central nightly, and started with the 2015-01-14-03-02-02-mozilla-central nightly.  It doesn't happen with e10s mode turned off, or (even with e10s mode on) in the 2015-01-13-03-02-05-mozilla-central nightly.

I tested in Windows 7 (fully updated), running in VMWare Fusion 7.1.0 (the current version) on OS X 10.8.5.

Regression range:
http://hg.mozilla.org/mozilla-central/pushloghtml?fromchange=3d846527576f&tochange=63006936ab99
I should also mention that I tested 32-bit builds in 32-bit Windows 7.
Keywords: regression
Nothing sticks out from the regression window. Useful information that would help move this along until someone from the gfx can look into this:
- Run mozregression and continue the bisection on the inbound builds.
- Post your about:support data. Try disabling d2d if it's on, switch to d3d9 layer if you're on d3d11.
tracking-e10s: --- → ?
I think I am able to reproduce the problem on my Windows 7 (64bit) VM using the build from comment #0, but I am also able to reproduce the problem using builds a day earlier. Toggling the hardware acceleration box in the advanced options makes the pages load again.
This is about:support with a working configuration? I guess it's difficult to get the about:support when the content is blank.
I found something rather interesting using about:support.

After using it once (and until I delete my old profile and create a new one), I get the same results (blank pages) in *all* the m-c nightlies I try, going back to the oldest one I tried (which happens to be 2014-12-09), until I both restart Windows and create a new profile.

I also eventually get the same results (without invoking about:support) if I keep trying any of my m-c nightlies and then quitting.  Eventually *all* of them show only blank pages for web content.  So my regression range from comment #0 is invalid.

Here's my about:support.  Note that it says my graphics driver has been blocked.  I suspect that, with a fresh profile, content pages only get displayed properly until the block is found (and downloaded to my profile).

I wonder why VMWare's standard/vanilla video "hardware" is considered to have issues.  I suspect it doesn't really, and that we should whitelist it.

Application Basics
------------------

Name: Firefox
Version: 38.0a1
Build ID: 20150202030232
Update Channel: nightly
User Agent: Mozilla/5.0 (Windows NT 6.1; rv:38.0) Gecko/20100101 Firefox/38.0
Multiprocess Windows: 1/1 (default: true)

Crash Reports for the Last 3 Days
---------------------------------

Report ID: bp-7c6fadbc-540c-4cac-a734-8b3ef2150202
Submitted: 22 minutes ago

All Crash Reports

Extensions
----------

Graphics
--------

Adapter Description: VMware SVGA 3D
Adapter Drivers: vm3dum
Adapter RAM: 832
Device ID: 0x0405
Direct2D Enabled: Blocked for your graphics card because of unresolved driver issues.
DirectWrite Enabled: false (6.2.9200.16571)
Driver Date: 7-29-2014
Driver Version: 8.14.1.51
GPU #2 Active: false
GPU Accelerated Windows: 0/1 Basic (OMTC) Blocked for your graphics card because of unresolved driver issues.
Subsys ID: 040515ad
Vendor ID: 0x15ad
WebGL Renderer: Blocked for your graphics card because of unresolved driver issues.
windowLayerManagerRemote: true
AzureCanvasBackend: skia
AzureContentBackend: cairo
AzureFallbackCanvasBackend: cairo
AzureSkiaAccelerated: 0

Important Modified Preferences
------------------------------

browser.cache.disk.capacity: 358400
browser.cache.disk.smart_size.first_run: false
browser.cache.disk.smart_size.use_old_max: false
browser.cache.frecency_experiment: 4
browser.places.smartBookmarksVersion: 7
browser.sessionstore.upgradeBackup.latestBuildID: 20150202030232
browser.startup.homepage_override.buildID: 20150202030232
browser.startup.homepage_override.mstone: 38.0a1
dom.mozApps.used: true
extensions.lastAppVersion: 38.0a1
network.cookie.prefsMigrated: true
places.history.expiration.transient_current_max_pages: 53674
plugin.disable_full_page_plugin_for_types: application/pdf
plugin.importedState: true
privacy.sanitize.migrateFx3Prefs: true

Important Locked Preferences
----------------------------

JavaScript
----------

Incremental GC: true

Accessibility
-------------

Activated: false
Prevent Accessibility: 0

Library Versions
----------------

NSPR
Expected minimum version: 4.10.8
Version in use: 4.10.8

NSS
Expected minimum version: 3.17.4 Basic ECC
Version in use: 3.17.4 Basic ECC

NSSSMIME
Expected minimum version: 3.17.4 Basic ECC
Version in use: 3.17.4 Basic ECC

NSSSSL
Expected minimum version: 3.17.4 Basic ECC
Version in use: 3.17.4 Basic ECC

NSSUTIL
Expected minimum version: 3.17.4
Version in use: 3.17.4

Experimental Features
---------------------
For me about:support works fine even when web-page content is completely blank.
(In reply to Benoit Girard (:BenWa) from comment #5)
> This is about:support with a working configuration? I guess it's difficult
> to get the about:support when the content is blank.

The about:support page worked whether the web content showed or not, similar to comment #7.
Milan, this sounds gfx related, can you triage?
Blocks: 1111396
Flags: needinfo?(milan)
So far, this is a problem in VMWare only?  What's the urgency for e10s on this configuration?

Also, about:support usually runs non-e10s, correct?
Flags: needinfo?(milan)
Any changes in behaviour if gfx.work-around-graphics-bugs is set to false?  Also, it wasn't clear if the regression range from comment 0 is valid or not, given the subsequent "and then about:support starts failing" comments - are we confident in the regression range?
> What's the urgency for e10s on this configuration?

Though I concentrate on the Mac, it's often useful to be able to run on other platforms to see if some bug is Mac-only or cross-platform.  However I can only run Windows in VMWare, and this bug basically prevents me from checking out e10s bugs on Windows.

> are we confident in the regression range?

No.  Juan didn't see my regression range, either.  And of course I no longer think it's reliable, for the reasons I explained above in comment #6.
> Any changes in behaviour if gfx.work-around-graphics-bugs is set to false?

I tried this (in the 2015-01-30 m-c nightly) and restarted.  At first it seemed to make no difference -- my home page was still blank.  But then I tried visiting www.mozilla.org, and that worked.
(Following up comment #13)

Oddly, though, visiting bugzilla.mozilla.org still doesn't work (I see a blank page).

Clearing the network cache makes no difference to these results -- I still see the correct contents when I visit www.mozilla.org.
Juan, could you try bugzilla.mozilla.org and www.mozilla.org and see if you get similar results?
Flags: needinfo?(jbecerra)
Never mind.  With yet another fresh profile I get a blank page visiting www.mozilla.org, too.

I remember thinking that, as of a few months ago, clearing the network cache no longer works reliably.
Flags: needinfo?(jbecerra)
> Any changes in behaviour if gfx.work-around-graphics-bugs is set to false?

So, ultimately (testing with a fresh profile), this makes no difference at all.
(In reply to Steven Michaud from comment #12)
> > What's the urgency for e10s on this configuration?
> 
> Though I concentrate on the Mac, it's often useful to be able to run on
> other platforms to see if some bug is Mac-only or cross-platform.  However I
> can only run Windows in VMWare, and this bug basically prevents me from
> checking out e10s bugs on Windows.

Reading my original question I realized it may have sounded like I was questioning your urgency; I was actually trying to find out how quickly this needs done :)  Either way, you answered the question, I understand what your workflow is now.
for investigation
tracking-e10s: ? → m6+
Summary: Contents blank for all pages in e10s mode running in Windows 7 in VMWare Fusion → Web content blank in e10s mode running in Windows 7 in VMWare
possibly related to bug 1127127
possibly related to bug 1135247
Assignee: nobody → gwright
A tester reports that disabling acceleration fixes this problem.

Note this also affects people using something called Citrix Receiver which is used for remote management and access.

http://www.citrix.com/go/receiver.html
I'm the tester mentioned on comment 22.

Comment 3 did helped to get past the never stopping spinners.

Had to uncheck "Use hardware acceleration when available" at about:preferences#advanced

The graphics details from about:support are below FWIW.

Graphics
Adapter Description	Citrix Display Driver (Citrix Systems - WDDM)
Adapter Drivers	vd3d vd3d32
Adapter RAM	0
Device ID	0x0405
Direct2D Enabled	Blocked for your graphics card because of unresolved driver issues.
DirectWrite Enabled	false (6.2.9200.16492)
Driver Date	8-9-2011
Driver Version	6.2.0.57
GPU #2 Active	false
GPU Accelerated Windows	0/4 Basic (OMTC) Blocked for your graphics card because of unresolved driver issues.
Subsys ID	040515ad
Vendor ID	0x15ad
WebGL Renderer	Blocked for your graphics card because of unresolved driver issues.
windowLayerManagerRemote	true
AzureCanvasBackend	skia
AzureContentBackend	cairo
AzureFallbackCanvasBackend	cairo
AzureSkiaAccelerated	0
I don't see "Use hardware acceleration when available" as an option when I run in e10s mode.

Does e10s mode require it?
(Following up comment #24)

Oops, brain fart.  "Use hardware acceleration when available" *is* available in e10s mode.  And this bug also goes away for me when I turn it off.
Whiteboard: [gfx-noted] → [gfx-noted][work around in comment 23]
OK, so this is caused by the "Windows 7 Platform Update", where they backported Direct2D 1.1 to Windows 7.

Using the DWrite versions as a reference point as about:support doesn't show the D2D version, my Win7 vm worked fine with DWrite 6.1.7601.17514, but is broken after installing the Platform Update which bumps that to DWrite 6.2.9200.16492.

Based on the fact that if I disable "Use hardware acceleration when available", it all works as expected, I'm going to hazard a guess that we're not falling back gracefully for some reason when D2D 1.1 is installed. As far as I'm aware, explicitly disabling h/w acceleration via that option, and having it disabled via the blocklist, should result in the same configuration.

I'll investigate this further.
I am also going to guess that the reason Steven didn't see the bug until the 2015-01-14 build of nightly is because the Platform Update installed on 2015-01-13.
So simply flipping the layers.prefer-d3d9 pref makes this work for me. Can you confirm whether that fixes this for you, whilst keeping the "Use hardware acceleration when possible" option set?
Flags: needinfo?(smichaud)
(In reply to George Wright (:gw280) from comment #28)
> So simply flipping the layers.prefer-d3d9 pref makes this work for me. Can
> you confirm whether that fixes this for you, whilst keeping the "Use
> hardware acceleration when possible" option set?

Note Bas says d3d9 on win7 isn't supported, see - 
https://bugzilla.mozilla.org/show_bug.cgi?id=1059804#c16
You may see odd side effects unrelated to this bug.
Yep, it's to do with D3D11 WARP not being used. I need to investigate this further, but I wanted to see if this and bug 1135247 are the same. I now think they are.
So here's what is going on here:

- We are on Win7 with D3D 11.1, and we try to create a WARP device (D3D's software rasteriser backend)
- This succeeds, and so gfxWindowsPlatform sets its state accordingly
- When we create a window, when it creates its compositor it tries to create a CompositorD3D11, which fails inside Initialize() as it tries to create a sync texture which won't work on Windows 7 (apparently there's a documented issue with creating shared textures with WARP on Win7)
- This causes a device reset and leaves our WARP device in an invalid state, and the machinery that's currently in place doesn't do a graceful fallback to Basic (OMTC) so stuff gets left in an invalid state. This results in blank pages and spinners and other nastiness.

This loop of death basically happens every time you load a new window (as we always try to create a D3D11 WARP device, then it always gets nuked because of the texture failure).

There are two parts for solving this:

- Fix D3D11 WARP to work on Win7 (this is covered in bug 1147728, and I have confirmed that patch fixes this issue)
- Fix fallback to Basic (OMTC) if our D3D11 device gets reset.

Fixing WARP is what I think this bug and all related bugs should be duped off, and Bas already has a patch up and it should land today or tomorrow. Fixing the fallback is less important, but I will file a new bug to track that and renom it for triage as it appears the fallback is only busted for e10s.
Status: NEW → RESOLVED
Closed: 9 years ago
Flags: needinfo?(smichaud)
Resolution: --- → DUPLICATE
Blocks: e10s-gfx
No longer blocks: 1111396
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: