And thus, Microsoft bites itself in its behind with Metro. As you all surely know by now, the Metro environment in Windows 8, and its accompanying applications, need to follow a relatively strict set of rules and regulations, much like, say, applications on iOS. For one type of application, Metro has already proven to be too restrictive and limited: web browsers. Microsoft has had to define a separate application class [.docx] - aside from Metro and desktop applications - just to make third party web browsers possible for Windows 8.

I'm unsure, but I honestly hope that they don't view the bar as simply matching IE10. In fact, I'm pretty confident they don't.

Well, you can blame Microsoft for their asinine Windows Store requirements

I don't really consider the majority of them asinine. I am sympathetic for the JIT related APIs missing (regarding memory mapping Win32 APIs for which there is no equivalent), but for 99% of the other things, it's not something which can be engineered around.

and for any desktop-mode-switching that may or may not be required.

Actually it's not even a question. It is indeed what will happen, according to Microsoft's document. It's obvious this is a suboptimal solution, and one which I think is detrimental to the experience. The ideal situation would be an alternative Firefox Browser in the Windows Store. Not some Frankenstein browser.

IE10 gets away with it, only because they're bundled, so the User doesn't have to jump through these aforementioned hoops.

You seem to forget that the majority of third-party Windows software still relies on Win32 and will for years to come, and it's not a trivial effort to port away from that. I expect that Firefox will hardly be alone in this point, even among Metro UI-ified apps.

They will actually, by definition, be mostly alone. Considering that this is the only supported configuration for deep, deep interop of Win32 and WinRT.

By comparison the subset of Win32 exposed to regular Metro Style apps isn't anywhere near this, so the amount of legacy code is considerably less.

I don't understand why take shortcuts at this point in the development though, they'll only create engineering pain points by not planning for Metro Style applications from the outset.

I just don't think this is a sustainable solution in the long term.

I fully expect them to, since as a browser they surely won't want to be barred from Windows on ARM. Whether Windows on ARM will be worth it to the likes of Adobe, Avid or Autodesk... I kind of doubt it.

It remains to be seen, but I think whoever is first able to counter bringing that kind of information density (where UI chrome is actually valuable) to a Metro Style application in a useable manner, will be onto something special.

If I were Adobe or even the MSFT Office guys, I'd be thinking of creative ways to work with the Metro Design Language to enable efficient workflows. I think it can be done, it's just not trivial or obvious.

I don't really consider the majority of them asinine. I am sympathetic for the JIT related APIs missing (regarding memory mapping Win32 APIs for which there is no equivalent), but for 99% of the other things, it's not something which can be engineered around.

Not being able to have a JIT (it's technically possible, but applications that do it would fail validation) is, by itself, enough to prevent any modern web browser from being a native Metro application.

That's not even considering everything else. It would require a massive effort to move everything over to WinRT. It wouldn't gain you anything. The new WinRT APIs are still accessible from a hybrid WinRT / Win32 application. The replacement APIs, like networking, don't actually offer any extra features over the existing Win32 APIs.

Besides, the architecture of Windows 8 requires that the Metro web browser be a hybrid application. That's just the way it works. The Metro web browser is determined by whatever the default desktop browser is. That's why, if you install Firefox on Windows 8 and set it as the default browser, the Metro version of IE 10 disappears.

Not being able to have a JIT (it's technically possible, but applications that do it would fail validation) is, by itself, enough to prevent any modern web browser from being a native Metro application.

Then this would have been an acceptable area to push for specific work on. A solution to this has implications beyond a browser, so getting some kind of brokered dynamic code generation API (For example, C# supports compiled Expression Tree's which offer limited dynamic code gen) would be more beneficial in the long run.

That's not even considering everything else. It would require a massive effort to move everything over to WinRT. It wouldn't gain you anything. The new WinRT APIs are still accessible from a hybrid WinRT / Win32 application. The replacement APIs, like networking, don't actually offer any extra features over the existing Win32 APIs.

Being conscious of mobile broadband networks is reason enough to warrant a rewrite. Firefox accommodates different networking subsystems already, and WinRT's async networking API would have been no different.

I think massive is a little overstated, but it'd require *some* effort. That's the entire point of WinRT, to be a clean break. I don't think it's asking for much, considering that the way we interact with these key things has fundamentally changed. The old rules no longer apply. So it's best to be resource conscious.

Besides, the architecture of Windows 8 requires that the Metro web browser be a hybrid application. That's just the way it works. The Metro web browser is determined by whatever the default desktop browser is. That's why, if you install Firefox on Windows 8 and set it as the default browser, the Metro version of IE 10 disappears.

If you were a pure Metro App, it wouldn't much matter which is the default browser because you'd be on the Start Menu regardless.

My point is, there's very little that was in the way of Firefox being a pure Metro Application. The upsides are immense, visibility in the Windows Store could probably go a long way towards Firefox adoption.