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.
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).
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?
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?
Status: UNCONFIRMED → NEW
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
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.
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.
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]
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.
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.
We could reopen story bug 831889, which this is already blocking.
yup that sounds good.
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.
Created attachment 712569 [details] [diff] [review] 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
Attachment #712569 - Flags: review?(jmathies)
https://hg.mozilla.org/projects/elm/rev/3303c0c89e81 Should be included in the migration of elm -> m-c
Status: NEW → RESOLVED
Last Resolved: 5 years ago
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
You need to log in before you can comment on or make changes to this bug.