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



7 years ago
5 years ago


(Reporter: sundbladc, Assigned: bbondy)



Dependency tree / graph

Firefox Tracking Flags

(Not tracked)


(Whiteboard: feature=work [metro-mvp])


(1 attachment)

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.
OS: All → Windows 8 Metro
Hardware: All → x86
Summary: Nightly (20.0a1) won't show Metro interface on x86 Win8 tablet → Elm Nightly (20.0a1) won't show Metro interface on x86 Win8 tablet
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).
Flags: needinfo?(sundbladc)
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?
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.

       Application Basics
              User Agent
              Mozilla/5.0 (Windows NT 6.2; rv:20.0) Gecko/20130108 Firefox/20.0
              Profile Folder
        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.disk.smart_size_cached_value 358400 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
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
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

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


Build Machine

Built from

Build platform

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 	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 	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
Flags: needinfo?(sundbladc)
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?
Blocks: 807669
Ever confirmed: true
Summary: Elm Nightly (20.0a1) won't show Metro interface on x86 Win8 tablet → Elm Nightly (20.0a1) won't show Metro interface on x86 Win8 tablet because of DX9 fallback
Whiteboard: [metro-mvp?]
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.
Assignee: nobody → netzen
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:

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.
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.
Whiteboard: [metro-mvp?] → [metro-mvp][LOE:1]
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.
Blocks: 831889
Whiteboard: [metro-mvp][LOE:1] → feature=work
Summary: Elm Nightly (20.0a1) won't show Metro interface on x86 Win8 tablet because of DX9 fallback → Work - Elm Nightly (20.0a1) won't show Metro interface on x86 Win8 tablet because of DX9 fallback
Hardware: x86 → All
Whiteboard: feature=work → feature=work [metro-mvp]
Version: 20 Branch → Trunk
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.
I meant to note that the workaround registry change solved the problem for both devices.
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.
Flags: needinfo?(asa)
We could reopen story bug 831889, which this is already blocking.
yup that sounds good.
Flags: needinfo?(asa)
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.
Posted patch Patch v1.Splinter Review
This is the fallback that we weren't detecting inside the CEH until this patch:
Attachment #712569 - Flags: review?(jmathies)
Duplicate of this bug: 756557
Attachment #712569 - Flags: review?(jmathies) → review+

Should be included in the migration of elm -> m-c
Closed: 7 years ago
Keywords: qawanted
Resolution: --- → FIXED
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.
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.
(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
OS: Windows 8 Metro → Windows 8.1
You need to log in before you can comment on or make changes to this bug.