829127 - Work - Elm Nightly (20.0a1) won't show Metro interface on x86 Win8 tablet because of DX9 fallback

Status: RESOLVED FIXED

(Firefox for Metro Graveyard :: Shell, defect)

Description

[sundbladc]

User Agent: Mozilla/5.0 (compatible; MSIE 10.0; Windows NT 6.2; Trident/6.0; Touch; .NET4.0E; .NET4.0C; .NET CLR 3.5.30729; .NET CLR 2.0.50727; .NET CLR 3.0.30729; Tablet PC 2.0; ASU2JS)

Steps to reproduce:

Installed Nightly 20.0a1 (elm) on my Asus VivoTab tf810 (x86 32-bit Win 8 Atom tablet, similar to Samsung Ativ, HP Envy, MS Surface Pro, and others). Selected Default Programs in Control panel, made Nightly default browser. Also tried setting Nightly as default browser in "Set program access and computer defaults", and from inside the browser, and various combinations of the above.


Actual results:

The "nice" Metro tile with the big fox shows on the start screen, but the browser always starts in desktop mode. Even with the -Metrodesktop argument set, the browser only shows the standard interface.


Expected results:

From what I read, Nightly should start as a Metro app, full screen and touch-enabled.

Comment 1

[Matt Brubeck (:mbrubeck)]

Can you run the elm Nightly in desktop mode, copy the information from about:support and about:buildconfig, and paste them as comments into this bug?

This might happen if Firefox is not able to use DirectX 10 acceleration (bug 756557).

Comment 2

[Brian R. Bondy [:bbondy]]

Could you also check this reg value: MetroDX10Available
inside HKEY_CURRENT_USER\Software\Mozilla\Firefox

If it is set to 0 can you try setting it to 1 and see if that helps?

Comment 3

[sundbladc]

Fixed! Setting HKEY_CURRENT_USER\Software\Mozilla\Firefox\MetroDX10Available to 1 solved the problem - Nightly started in the Metro interface after being set as the default. 

Also, here are the about:support and about:buildconfig contents (after setting the value above to 1). Thank you for your quick responses and the solution.

about:support
     
       Application Basics
            
              Name
              Firefox
              Version
              20.0a1
              User Agent
              Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20130108 Firefox/20.0
              Profile Folder
            
        Extensions
              Name
              Version
              Enabled
              ID
      
        Important Modified Preferences
          
            Name
            Value
browser.cache.disk.capacity 358400
browser.cache.disk.smart_size.first_run false
browser.cache.disk.smart_size.use_old_max false
browser.cache.disk.smart_size_cached_value 358400
browser.link.open_newwindow 2
browser.places.smartBookmarksVersion 4
browser.startup.homepage_override.buildID 20130108083104
browser.startup.homepage_override.mstone 20.0a1 
browser.tabs.autoHide true 
browser.tabs.warnOnClose false
dom.w3c_touch_events.expose true
extensions.lastAppVersion 20.0a1
network.cookie.prefsMigrated true
places.database.lastMaintenance 1357764566 places.history.expiration.transient_current_max_pages 51477
plugin.disable_full_page_plugin_for_types application/pdf privacy.sanitize.migrateFx3Prefs true
      
        Graphics
Adapter Description Intel(R) Graphics Media Accelerator
Adapter Drivers igdumd32
Adapter RAM 0
Device ID 0x08cf
Direct2D Enabled Blocked for your graphics driver version.
DirectWrite Enabled false (6.2.9200.16433)
Driver Date 10-24-2012
Driver Version 9.14.3.1099
GPU #2 Active false
GPU Accelerated Windows 1/1 Direct3D 9
Vendor ID 0x8086
WebGL Renderer Google Inc. -- ANGLE (Intel(R) Graphics Media Accelerator)

AzureCanvasBackend Cairo
AzureContentBackend none 
AzureFallbackCanvasBackend none

        JavaScript
      
Incremental GC true
         
Accessibility
Activated true
Prevent Accessibility 0
          
        Library Versions
      
Expected minimum version Version in use
NSPR 4.9.5 Beta 4.9.5 Beta
NSS 3.14.2.0 Basic ECC Beta 3.14.2.0 Basic ECC Beta
NSSSMIME 3.14.2.0 Basic ECC Beta 3.14.2.0 Basic ECC Beta
NSSSSL 3.14.2.0 Basic ECC Beta 3.14.2.0 Basic ECC Beta
NSSUTIL 3.14.2.0 Beta 3.14.2.0 Beta

  about:buildconfig

about:buildconfig
Build Machine
w64-ix-slave07

Source
Built from http://hg.mozilla.org/projects/elm/rev/d9088c8f8695

Build platform
target
i686-pc-mingw32

Build tools
Compiler 	Version 	Compiler flags
e:/builds/moz2_slave/elm-w32-ntly/build/obj-firefox/_virtualenv/Scripts/python.exe -O 
e:/builds/moz2_slave/elm-w32-ntly/build/build/cl.py cl 	16.00.30319.01 	
-TC -nologo -W3 -Gy -Fdgenerated.pdb -we4553 -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oy-
e:/builds/moz2_slave/elm-w32-ntly/build/obj-firefox/_virtualenv/Scripts/python.exe -O 
e:/builds/moz2_slave/elm-w32-ntly/build/build/cl.py cl 	16.00.30319.01 	
-TP -nologo -W3 -Gy -Fdgenerated.pdb -wd4345 -wd4351 -wd4800 -we4553 -GR- -DNDEBUG -DTRIMMED -Zi -UDEBUG -DNDEBUG -GL -wd4624 -wd4952 -O1 -Oy-

Configure arguments
--enable-update-channel=nightly-elm --enable-update-packaging --enable-jemalloc --enable-signmar --enable-profiling --enable-metro --enable-js-diagnostics --enable-warnings-as-errors

Comment 4

[Matt Brubeck (:mbrubeck)]

Can we investigate why this wasn't working by default, and if we can do anything to make Metro work out of the box on this type of hardware/drivers?

Comment 5

[Brian R. Bondy [:bbondy]]

Yup I'll take a look, sounds like a bug in the detection, maybe there's some kind of fallback that the metro browser uses that we don't handle in the detection in the CEH.

Comment 6

[Brian R. Bondy [:bbondy]]

sundbladc, could you run a test to see if this was caused by an intermittent problem, or hardware change, or driver change, or if it's a consistent problem in the detection?

The test is just to delete this entry:
HKEY_CURRENT_USER\Software\Mozilla\Firefox\MetroDX10Available

Then next time you start the metro browser it will be re-created.
Let me know the value, if it happens to be 0, please reset it to 1 for the time being.

Comment 7

[Brian R. Bondy [:bbondy]]

Just marking this as metro-mvp since it' a bug and could prevent people from running Metro Firefox.

I investigated this and found the reason why.  The CEH will disallow using Metro if D3D10 is not available. But I found that D3D10 is not needed.  We do need D2D10 though. So we need to update this to not require D3D10.

Comment 8

[sundbladc]

Hi!
Deleted the MetroDX10Available DWORD, after which Nightly started in desktop mode from the Start screen. The MetroDX10Available key was added automatically after this start, with a value of 0. Had some trouble getting Nightly to start in Metro mode again after resetting the key to 1 (got the Metro splash screen but then got sent right back to the Start screen) but did not investigate further.

Comment 9

[Asa Dotzler [:asa]]

I see this same problem on two Intel Atom-based tablets. I'll wager this is a widespread problem and Atom tablets are presumably going to be a big deal because of their solid tablet-like battery life.

Comment 10

[Asa Dotzler [:asa]]

I meant to note that the workaround registry change solved the problem for both devices.

Comment 11

[Brian R. Bondy [:bbondy]]

Asa if we can get a story around this, I can take this bug this iteration and let Marco know. Having the Metro browser working on win8 devices should be a p1.

Comment 12

[Matt Brubeck (:mbrubeck)]

We could reopen story bug 831889, which this is already blocking.

Comment 13

[Brian R. Bondy [:bbondy]]

yup that sounds good.

Comment 14

[Brian R. Bondy [:bbondy]]

So it turns out that d3d is needed and the bug is that when it's not available we use cairo, and cairo has support for d3d 9.3.  Fix coming soon.

Comment 15

[Brian R. Bondy [:bbondy]]

Attachment: Patch v1.

This is the fallback that we weren't detecting inside the CEH until this patch:
http://dxr.mozilla.org/mozilla-central/gfx/cairo/cairo/src/cairo-d2d-surface.cpp.html#l327

Comment 17

[Brian R. Bondy [:bbondy]]

https://hg.mozilla.org/projects/elm/rev/3303c0c89e81

Should be included in the migration of elm -> m-c

Comment 18

[timfelgentreff]

This patch does create the D3D registry key now, if the fallback on first startup to feature level 9.3 worked. However, in prefs.js of the MetroFirefox profile the key "gfx.direct3d.checkDX10" is then to false after the first exit. This has the effect that on the next startup, it doesn't do the same probing for feature levels, and just goes ahead and tries to create a render layer requesting feature level 10 (since there is no information in the key which feature level is required). Creating the render layer with feature level 10 fails, and MetroFirefox still crashes on startup.

Comment 19

[Brian R. Bondy [:bbondy]]

I think you may be having a different type of crash. We don't use gfx.direct3d.checkDX10 anymore.  See bug 844954 for that change.  

If you're still experiencing a crash with the latest nightly after the fix in bug 844954 though, please post a new bug as it could be any type of other startup crash as well.

Comment 20

[timfelgentreff]

(In reply to Brian R. Bondy [:bbondy] from comment #19)

You're right, that patch indeed fixes it. For some reason my nightly failed to update update since 03/22, manual upgrade fixed it